Making Project Hospital: A realistic approach to medical simulation

Lead programmer Jan Beneš at Oxymoron Games chats with Gamasutra about the making of the successful medical sim Project Hospital.

Project Hospital is the latest entry into the field of medical center simulations, which is usually covered in a tongue-in-cheek way, such as with both Bulfrog and Krisalis’ Theme Park Hospital and Two Point and Sega’s upcoming Two Point Hospital.

Oxymoron Games’ Project Hospital takes a more realistic approach in terms of the medicine involved, although some side aspects are simplified or even fictionalized for a better play experience. Lead programmer Jan Beneš kindly answered some questions about its development for us.

Origins of Oxymoron Games

The origin of Oxymoron Games can be tracked some years back, when most of the team members were still employees in different bigger studios in Prague or Helsinki, thinking (and talking) about working on our own games one day. The experience with a variety of games from third-person action games, like Mafia II and III or Quantum Break, to different genres like sports or simulation games turned out to be really useful when starting a new project from scratch.

Genre competition

Reality and depth seems to have worked really well for us. Most of the recent games tackling the hospital theme are very casual and simple, their content has mostly nothing in common with real hospitals. On the other hand Project Hospital is focused on players who want a challenging approach and who want real medicine. The complexity gives you a plenty of options what to play with and what to build and a long learning curve gives you small challenges in many aspects of gameplay (easy to learn, hard to master). And all of this has a basis in real world medicine with a slight educational potential. I think this is where Project Hospital excels.

Realism in a medical sim

I admit that balancing this game between gameplay and reality was quite tricky, but overall gameplay should always come first. I could say that Project Hospital is as real as possible, but still just a game - and a game must be fun to play. That's why there are no STDs or dying children, that would be just too depressing, or too specific details like vital functions where you would have to consider the values of heartbeat, blood pressure, temperature and others, because that would make the game unplayable for people without medical background (and for some of us devs as well).

Choosing what to simulate

Taking in account how complex the game is and how small a team we are (smaller than for example the team behind Prison Architect), it's true that there have been some hard decisions and some originally planned features had to be simplified or postponed after release - typically variations of the same system (ambulances vs. helicopters, elevators vs. stairs).

Sometimes the reasons for going with a simpler solution were both the implementation cost and design decisions, especially when the features would make the game even more demanding for the player to understand and learn.

Letting the player to focus on what they want

One of the main design pillars has been to allow the player to focus on any of the main aspects of the game while the rest will work mostly automatically. Another example would be prefabs in building mode.

The option to go hands-on with individual patients is clearly the favorite part of the game for a lot of players and a it definitely got lot of attention during development. The players can control any aspect of what happens with the patient by planning examinations and treatments, figuring out the diagnosis or assigning doctors and departments. Still, when managed correctly, the staff should be able to handle most cases independently and only notify the player if there is a problem or a crisis.

Designing the UI

The user interface has definitely been one of two biggest challenges (second one being the complex rules of how the patients flow through the hospital, while the player can intervene at any point).

Nobody in the team had previous experience with UI design, so there has been a lot of 'learn as you go' along the way and many parts of the interface underwent quite a few iterations, as also the underlying systems evolved during development.

We're happy that we managed to implement quite a few quality of life features like different levels of transparency, guides on the floor when placing objects and detailed tooltips for anything in the user interface, the whole management/logistics view turned quite nicely and in a way it presents itself almost like interactive infographics–but there are always some ideas how to improve the interface further.

Level design in a hospital sim

The management side and especially hiring correct staff has more weight when it comes to running a hospital smoothly, but the layout of course plays an important role as well. In any game with a relatively fast time scale (our day lasts for about an hour) the walking times are really important so both the layout of the hospital, elevator placement and even layout of individual rooms matter. The effect is even more prominent with inpatients, as a nurse needs to go get a stretcher to transport the patient.

Implementation choices

The game is built with Unity, which was a reasonable choice, but we're basically only using the UI system and renderer and no asset store packages at all. The game itself is mostly a standalone codebase written in C# with quite a few custom systems - it's sometimes a real lifesaver to have direct access to code for both debugging purposes and for easy changes.

For example our animation system allows us to easily create random character variations, change clothes, trigger events and we can develop specific tools as needed. Another example is pathfinding, there's a lot of rules like access rights or elevator usage which make it impractical to use the Unity navigation system, so a custom (not very fancy) multi-threaded system based on A* is what we went with.

Do you now have hypochondria?

Haha, luckily not. Fun fact: hypochondria was one of the first testing medical conditions in the alpha version of the game and had a specific examination that was uncovering it.

One of the best parts of the experience compared to working on triple-A where everybody has a very specific role and is shielded from the outside world, was working with the community. First people who got in touch were actually professionals in the medical field who did some free consultancy for us and even helped with the medical texts in the game, like descriptions of diagnoses or symptoms.

We ran a closed beta a few months before release with a few hundred people and it really helped us catch a lot of issues early. The game shipped with eight community-translated languages (which has now grown to 13) and more are on the way. Generally this really exceeded our expectations and gave us a nice morale boost along the way.

Latest Jobs

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Programmer

The Pyramid Watch

Game Designer (RTS/MOBA)

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Technical Combat Designer

Digital Extremes

Lead AI Programmer
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more