As I’ve started trying to figure out how Acute Care was going to play, I’ve tried to keep my design goals in mind all the time. The main “educational” point I wanted to get across was that cooperation and teamwork are absolutely vital, so I started by identifying the main resource that must be shared by the nurses on this unit. That resource is, of course, time.
Time = Actions
So while it’s not terribly original in coop games, I’ve decided that time will be represented in the game by action points. Since each turn is supposed to be one hour of the 12-hour shift, I’ve broken it down into each nurse having 6 actions each hour (obviously representing 10 minutes each). Since some level of realism is another design goal, I wanted it to be tied to “real life” as closely as I could, and I think that this number of actions will be a good balance between that and still being reasonable and manageable for players.
Obviously, a game about nursing must deal with patients. In real hospitals, nurses on medical/surgical units tend to care for roughly 4-6 patients at a time. So I plan on players starting with 4 patients, but then getting new admissions and having the possibility of discharges and transfers throughout the game to have this number fluctuate. The max will probably be 6 patients each, however (even though in real life it sometimes may be pushed further than that).
Patients will be represented by cards that are placed into spots (“beds”) on the board. They will have some sort of keywords (Surgical, Medical, Isolation, etc.) and an Acuity Level.
Acuity is a measure of how sick someone is (and often, how much work they are to take care of), which I’m going to rate on a scale of 1 (ready to go home) to 5 (critical condition). Players will be able to spend actions to improve acuity and even discharge patients once their acuity drops to level 1. Event cards and maybe some other effects will also potentially worsen acuity. My plan right now is to track Acuity using a d6 on the card itself, which can be dialed up or down as their condition changes.
One key to patients is that they will also require the players to spend actions just to care for them. Right now, I think that I’m going to have each patient present at the beginning of a turn require players to spend one action point. I’ve considered having this change based on acuity, but I’m worried about that being a little too complicated or cumbersome. I also have some ideas about how I could still use higher acuity to make their lives a little harder with the Event Cards I’ll talk about in a minute.
I’m still trying to work out exactly how I’m going to assign starting patients. Just to ensure balance, I’ll probably build a patient pool with a defined range of acuity levels that will be either randomly dealt out to the players or assigned by the Charge Nurse.
The thing I’ve probably waffled about most in this conceptual stage of design is the role of the Charge Nurse. In real life, the Charge Nurse makes assignments, schedules lunches and breaks for staff, communicates with other units and administration, and generally helps out and oversees what’s happening on the unit. In some areas, they also take a smaller patient assignment, while in others they do not.
I really want to have this role in the game, but don’t know exactly how to do it. In 4- or 5-player games, it would probably be interesting enough to have a person filling the role. But with 2 or 3, I think it’d be sort of boring, so I’d probably just make it a pool of extra actions that the players could spend as they needed them. The number of actions given to the Charge Nurse would probably need to scale as well, maybe something like 2 per player, or 2+1 per player, but that can be ironed out in playtesting. But regardless, I really like having someone who will make decisions about assignments and admissions, and hope that it can be worked out.
As with all cooperative games, something has to happen to make things worse in the game. Each round, players will have to draw a card from this deck, but I’m not sure right now whether all the cards will be drawn at one time or if players will draw them on their turn. I’ll get into that at another time, but for now, I think I’m pretty clear about there being 3 types of cards:
1) New Admissions – New patients that pretty much function as other patients do, but would require spending 2-3 actions to admit them.
2) Events – Things that happen to throw a curveball to the unit. The “big one” would be a Code Blue!, which is a medical emergency that would end up eliminating a patient (either through death or transder to the ICU), but would require some crazy amount of actions to complete (4-8, maybe depending on the number of players). Other events would be things that would require actions to prevent a patient’s Acuity from worsening, losing points from their Quality score (which I’ll get to next), or other bad things.
3) Attachments/Conditions – Generally, these would be things that modified patient cards, such as being confused, having a difficult dressing change, or other stuff that would usually require more time/actions. They would be placed based on Acuity and keywords, so players would have some choice about where to put them within certain guidelines.
The Goal of the Game
One of the hardest things I’ve had to define about Acute Care so far is how to win or lose. In a real hospital, there are a lot of things to consider when it comes to evaluating success, such as patient outcomes, patient satisfaction, staff morale, financial solvency, and reputation in the community. I toyed with all sorts of ways to represent these things, and in the end decided to sort of clump them all together into the idea of Quality.
Quality will be the overall “score” that you’ll be working towards in the game. Points can be gained or lost based on events that happen through play, and then there would be some threshold at the end of the game that would be considered “winning”. There would probably also be some lower level that would cause the game to be lost immediately if it ever got that low (’cause all coop games need auto-loss conditions!).
At this point, though, I really don’t have any sort of idea how big this scale might be or what kind of levels would be considered success or failure, and I figure that it’ll take some considerable playtesting and tweaking to figure it out.
Enough for now…
I’ve got more, but I think this is probably enough for right now. In my next article, I’ll cover some of the other ideas I’ve had for mechanics, as well as some of the problems that I foresee already. Until then, feel free to comment and even make suggestions, as well as giving me more feedback about whether or not this whole shebang is interesting or not.