Project Hospital is a game developed by indie studio Oxymoron games (Prague, Czech Republic). In it, you build and manage every single detail of your own hospital – and you can diagnose and treat patients as well! Launched in 2018 on Steam, the game features a wealth of real-world-based medical expertise, equipment and diseases and injuries, counting with an in-depth diagnosis process.
To understand how all of this is possible in a game, the Journal of Geek Studies interviewed Jan Beneš, lead programmer at Oxymoron games. We uncovered the story behind Project Hospital, which you can read below.
Q: There are a few hospital and “medical” sim games around, but Project Hospital is a fresh and more down-to-Earth example of this subgenre. How the idea for this game came to be?
A: The story began like this: a small group of developers met in early 2016 to discuss starting a new studio and hopefully agree on the first project. Most of us are now team members or co-founders of Oxymoron games and as it turned out, Project Hospital was definitely a good choice of a game that we’d be both able to create with a team of 2–4 people and which would find its place on the market thanks to the combination of theme and realistic settings. The original pitch itself came from Roman, who then took the role of lead designer and main artist on the project.
Q: Have you or anyone in the team worked in a hospital before?
A: Actually yes, one of our designers has some experience from medical school combined with an internship in a hospital, and while he took a different career path later, his familiarity with the field was essential when choosing and creating content for the game.
Q: Did you contact staff from hospitals (admins, nurses, physicians, etc.) for advice when developing the game?
A: When we announced that the project was in development, quite a few real-life doctors and professionals in the medical field got in touch and we spent a lot of time discussing different topics in a private section of our forums. This really helped, for example, with choosing the best terminology for different aspects of the game and to some extent to see if we can get away with some of the necessary steps needed when transforming a very complex topic into a game, while advertising the realistic settings.
Q: How much realism did you set out to include in Project Hospital and how this realism was balanced with gameplay and entertainment?
A: The foundations based on real-world medicine gave us clear boundaries, but to create an engaging game, gameplay must come first. To be more specific, this means choosing a correct level of simplification and turning complex material into rules like “examinations uncover symptoms”, “uncovering enough symptoms leads to a clear diagnosis”. In the next step, it was necessary to adjust a lot of values to create interesting cases for the players to solve — for example, the occurrence rate of certain symptoms in different diagnoses was needed to be set in such a way that would limit cases where it’s immediately clear what the patients are suffering from after first examination.
The process was a bit easier on the side of hospital management — and while this wasn’t the actual goal and we carefully balanced the economy aiming for a challenging experience — it turns out that the simulation is actually very close to the American healthcare system, which is both fascinating and pretty scary.
Q: So, let’s delve into some of that gameplay now, shall we? What is the players’ actual goal in Project Hospital?
A: In our elevator pitch for Project Hospital we always mentioned that the game would allow players to focus on different aspects, whether it is the building part with all the little details, managing a huge hospital and making it as efficient as possible, or taking care of individual patients. The latest version of the game still follows these rules as far as possible and on top of that, for players looking for more structure, we added a short campaign with some interesting tasks to undertake.
Q: Does the game allow specialization in particular subfields of medicine? Like making your hospital a reference in ophthalmology or oncology, for instance.
A: The content is indeed structured into individual departments and you can focus on any of them in any particular build, as well as running only a clinic. The five main fields available in the base game include for example cardiology, neurology and orthopaedics, with more planned for future DLCs and more also getting added by the community thanks to mod support. Oncology would be an example of a field we didn’t select ourselves, but has been already added to Steam Workshop.
Q: From what we’ve seen, there are different objectives to be met, like solving complex cases, keeping staff and patients happy, and make profit with your hospital business. Is there a trade-off between these objectives in the game?
A: The game generally rewards you for taking good care of your employees and patients alike, so there should be no conflict between being a good manager and helping your staff with complicated cases when needed. For the players who want to focus on one specific goal, the game tries to help by making almost every aspect automated to some extent. Not interested in building? Try one of the pre-built hospitals or place whole rooms using the collection of prefabs. Not up to dealing with individual patients? Hire experienced staff and let them do their job.
Q: One cool thing in Project Hospital is to solve difficult cases. When doing so, the player is unknowingly making use of decades of real medical research. Is there a nod in the game towards scientific research and how medical knowledge evolves?
A: From this point of view we use one snapshot in the development of modern medicine — the systems are already pretty complex and quite demanding for new players, so for example researching new and more effective types of medicine didn’t become a priority. There’s definitely enough challenge already in finding the correct diagnosis, uncovering all potentially dangerous hidden symptoms and treating the patients on time.
Q: Unfortunately, there is a current trend of once-eradicated diseases making a resurgence. So, when you’re dealing with an infectious disease in the game, is there any discussion or statement about prevention, vaccination, etc.?
A: This is definitely an interesting topic, but has mostly fallen out of scope of the main release — that said, we’ll still have opportunities to tackle some of these aspects in the future and it’s true that with the recent news regarding the coronavirus outbreak, we’ve been even getting similar requests from the player community.
Q: Do you think there is an educational potential for Project Hospital?
A: In a way, Project Hospital contains a pretty extensive encyclopedia of medical conditions, symptoms and diagnostic methods. While, for example, a lot of the probabilities in the background are balanced more towards generating interesting cases than strictly following reality, there’s a lot to learn from the game.
And while we can’t really share more details at this moment, a couple of institutions have been evaluating the game for the use in training (I guess more for managers than doctors, but still…).
Q: So far, have you received feedback from the medical community? What has that been like and how does it differ from regular player feedback?
A: We’re amazed how big a part of the player base are actual doctors or people with doctors or nurses in their family — and an obvious observation, their real-world experience indeed makes it much easier for them to get into the game.
About the Team
Oxymoron games is an indie game studio based in Prague, founded by a small group of Czech industry veterans. They have experience both at home and abroad, having worked on various game genres and interesting titles like Mafia II & III, Quantum Break, Top Spin 4 or Euro Truck Simulator. In 2016, they finally found themselves at the right place in the right time to have a shot at becoming independent. After the successful release of their first game, Project Hospital, they’re currently working on more content and supporting their player base, while preparing for future adventures.
The Climate Trail is a new and totally free game for PC and mobiles developed by Willian D. Volk. The game takes place in the in future, when our inaction regarding the climate crisis has rendered much of the world uninhabitable. The player leads climate refugees as they flee from ever worsening conditions, combining adventure, survival and visual novel elements. The Climate Trail follows the footsteps of the famous series The Oregon Trail (MECC, 1971–2011).
The Journal of Geek Studies interviewed Willian D. Volk to understand how The Climate Trail came to be. You can read the full interview below.
Q: Firstly, thank you for making The Climate Trail; the world desperately needed it. Being such a hot topic (no pun intended), it’s amazing no one in the video game industry has faced it heads on yet. So how did you become the first one to step up to this task?
A: The mainstream video game industry is risk-adverse because unlike film, there is no secondary markets (cable, etc.) for their games. With high budgets, they don’t take big risks and rely on franchises (i.e., Call of Duty, Overwatch, Grand Theft Auto) for most of the revenue. There’s also an aversion to tackling controversial topics. There are some indie games that have addressed the climate issue, but The Climate Trail may be the first to put players into a post climate-apocalypse world.
Q: Before The Climate Trail, did you have any experience in communicating about climate change? Or maybe even joining up some marches and protests?
A: I have degrees in Physics, a wife who used to work for the EPA and a brother who is a meteorologist. I’ve done way too much online debating on the issue, which was one of the motivations for making this game. I have participated in some climate events as well.
Q: As the game’s title and website make clear, it has drawn inspiration from The Oregon Trail. The Oregon Trail series is classified as ‘educational games’. Do you see The Climate Trail equally as an educational game or more as a call to action?
A: My goal is to add more educational content into the game so it can be a resource for climate information, but I also want it to be a call to action. Both are important.
Q: Would you like to see The Climate Trail being used in classrooms?
A: I do. This is why there’s no “roving band of cannibals” or other violence in the game. I present information about climate change in the title and expect to have the game serve as a resource for climate education.
Q: To create The Climate Trail, did you use models and predictions made by climate scientists? If so, which studies and reports have you used?
A: Yes, here are some studies and information about feedback loops.
What Lies Beneath: The Understatement of Existential Climate Risk
Existential Climate-Related Security Risk [foreword by C. Barrie]
Turn Down the Heat: Why a 4°C Warmer World Must be Avoided
Scientific articles by Farquharson et al. (2019) and Schneider et al. (2019)
Opinion articles by Hewett (2019) and Kristof (2019)
Q: To many (if not most) people, science alone is not enough reason to take action. The emotional impact of a game might be more crucial, and art might play a bigger role here. The Climate Trail has all of that, so how did you approach the mix and balance of science and emotion?
A: I’ve always believed that games can have social value. Chris Crawford’s 1985 classic game of geopolitical brinkmanship, Balance of Power, showed the futility of nuclear war. There are other examples, the 1997 PlayStation game Oddworld: Abe’s Oddysee covered the exploration of workers in a moving way. For me the example that best represents a creative effort that moved me to tears is the 1959 film On the Beach.
On the Beach scared me and I’m sure many other “cold war” children (and adults). The ending scene of the film shows a deserted world with banners expressing futile hope in a dramatic image. I want to invoke the same feelings about our ever more likely climate apocalypse as On the Beach did for nuclear war. As the scientist in that film says: “Who would ever have believed that human beings would be stupid enough to blow themselves off the face of the Earth?”
I simply can’t believe we’re stupid enough to cook ourselves off the face of the Earth. If I can achieve 1/10th of the emotional impact of Oddworld or On the Beach I will be happy with the effort.
Q: In The Climate Trail, players must survive a journey from Atlanta, USA, to Canada, across a climate-wrecked landscape. Did you choose this area for any particular reason?
A: Single highway route made design easier, all the locations are far enough above sea level to still be passable even if all land ice melts. I’ve been to that Canadian town as well.
Q: The USA in The Climate Trail looks terrible. In what year exactly does the game take place?
A: I’m deliberately not specific. Kate (the scientist) mentions Greenland Ice Melt when she was in college (dog sled picture) so the idea is it could be anywhere from 30 to 50 years or more.
Q: We love that the game’s difficulty levels are represented by greater increases in global temperature. How do the different temperature increase scenarios change the gameplay?
A: They effect heat wave and storm frequency, how many seeds you have at the start and the odds of finding supplies and capturing rain.
Q: You funded the game yourself and made it available to the public for free. Why did you opt for that approach?
A: It’s easier for climate organizations to support a game if it’s not a commercial venture. Also want to get it into schools.
Q: Ultimately, what is your hope for The Climate Trail?
A: Have it become an educational resource (as we add more climate info) and as with On the Beach create emotional impact that moves people to action. I want to see millions playing it.
About the Team
William D. Volk is a game developer, founder of Deep State Games, and environmental advocate. He began his career in 1979 helping to launch the computer game division of Avalon Hill. He has worked at Activision and Lightspan and produced over 100 educational adventures. George Sanger, also known as “The Fat Man”, is a musician who has composed music for several video games, including Wing Commander and SimCity 2000.
 Farquharson, L.M.; Romanovsky, V.E.; Cable, W.L.; Walker, D.A.; Kokelj, S.V.; Nicolsky, D. (2019) Climate change drives widespread and rapid thermokarst development in very cold permafrost in the Canadian High Arctic. Geophysical Research Letters 46: 6681–6689.
 Schneider, T.; Kaul, C.M.; Pressel, K.G. (2019) Possible climate transitions from breakup of stratocumulus decks under greenhouse warming. Nature Geoscience 12: 163–167.
Squids Odyssey is a role-playing game by French studio The Game Bakers. It is the latest entry in the Squids franchise, released in 2014 for Nintendo 3DS and WiiU, and more recently, in 2018 for PC and Nintendo Switch.
The fun fact about our Squids games is that we were actually all fascinated by octopuses and cephalopods in general long before we created the game. We even almost named our game studio “Happy Squids”… It was when we were working on the game mechanics and looking for some characters that could be “stretchable” on an iPhone screen that we thought about “tentacles”. Then we knew it was a perfect fit! We started designing our little heroes inspired by real octopuses, squids and other cephalopods.
We did a lot of research to get inspiration on shapes and colors, but of course there is also a lot of redesign in cartoon style so sometimes it might be hard to see the direct reference. But you can still recognize a few: for instance, Clint was inspired on the vampire squid. Baron, the bad guy in the story, is inspired by a more regular octopus.
We also looked at shrimps and crabs for the enemies. The big boss of the first game is a coconut crab, while a basic enemy you meet in the game is a hermit crab. You can tell the influences directly from the designs.
We took inspiration from other real underwater fauna and flora for the environment design. Even their habitations or their helmets are inspired by things you can find on the bottom of the sea. And in the comic book, we extended the character design to fish; for instance, one of the characters was inspired on a swordfish. In our game, squids and turtles actually cooperate, even though this might not be the case in real life.
For simplification, our little characters only have 4 arms. It’s funny that we’ve been told by some members of our Japanese audience – experts in octopuses and squids – that our little heroes did not look enough like these animals!
ABOUT THE TEAM
The Game Bakers are an indie game studio founded by Emeric Thoa and Audrey Leprince, and based in Montpellier, France. Besides the Squids franchise, they are also responsible for the acclaimed Furi and the upcoming Haven.
 Squids and cuttlefish have 8 arms and 2 tentacles. Octopuses have 8 arms and no tentacles.
 Shrimps, crabs and lobsters are crustaceans and belong to the Phylum Arthropoda, alongside insects and arachnids. They are not related to cephalopods, which belong in the Phylum Mollusca alongside snails and clams.
In this study, I investigated whether Brazilian independent (“indie”) game developers use methods and techniques derived from Software Engineering when developing their games. The hypotheses raised in this article are that, even with the vast literature available to guide good development practices, independent developers do not have specialists in their teams in the role of engineer; also, they do not use Software Engineering knowledge when developing their games. All this sums up to several difficulties during game development. Thirty-five indie developers from four Brazilian Internet communities and 13 Facebook groups were interviewed for this study, showing that indie game development in Brazil still lacks professionalism, especially regarding methodological aspects.
DELIMITATION OF THE SUBJECT
A definition of “indie” is given by Lemes (2009: 27 [my translation]): “a project to be developed without the financial contributions of big companies (…) a game developed by a small team, or individually, by pure passion of the subject or simply to one day make money and start a career in the area of creation and development of digital games” (see Wikipedia, 2017b, for more information).
There is a bunch of indie games out in the market, some known far and wide, like Minecraft and Angry Birds, but some famous only within the gaming community, like To the Moon (Fig. 1) and Stardew Valley. In the Brazilian indie scene, Chroma Squad (Fig. 2) and Momodora (Fig. 3) are good examples of the latter case.
Figure 1. To the Moon. Screenshot of the game.
The process of game development is (or should be) bustling with engineering techniques, such as project organization, modeling, software metrics, surveying requirements, and software documentation. According to Pressman (2010: 31), Software Engineering “encompasses a set of three fundamental elements – methods, tools and procedures – that enables the manager to control the software development process and provides the professional with a basis for building high quality software productively.” However, it is important to point out that Software Engineering was not always present in the development processes among professionals in the field. Pressman (2010: 8) states that at first “programming was seen as ‘an art form’. There were few formal methods and few people used them. The programmer often learned his trade through trial and error. The technical bragging and the challenges of building computer software have created a mystique that few managers cared to penetrate. The software world was virtually undisciplined.”
Figure 2. Chroma Squad. Screenshot of the game.
A digital game is by its nature a computer software and it must go through similar, although not identical, processes during their development. Velasquez (2009: 30 [my translation]) states that, contrary to the usual popular opinion, a “computer game is not just a toy, but a large and complex software project developed by a vast team of professionals.” Therefore, similar problems can be detected during the development phases of games and “regular” software, such as: the long production time, the difficulty in measuring progress while the software is being developed, the lack of data collection during development, the late detection of errors, etc. (Pressman, 2010).
Figure 3. Momodora: Reverie Under the Moonlight. Screenshot of the game.
Moreover, even with similarities, game development differs in some instances from conventional software development (Morais & Silva, 2009) and still lacks a Software Engineering model dedicated to it (Velasquez, 2009). The importance of engineering methods in game development (and design) are even more obvious when thinking of the final game/software as a product for the market (Lemes, 2009; Lacerda & Selleri, 2012).
In summary, there is agreement in the literature that there is a need for engineering methods in game development, which should be different from conventional methods and adapted to the specificities of games. By applying such methods, it is possible to maintain a stable project progress control, which will in turn result in a better product. As pointed out by Lacerda & Selleri (2012), the best candidate for this methodology lies in the area called Software Engineering.
The main roles on a team of game developers are: Programmer, Artist, Designer, Producer, Tester, Composer, Sound Designer and Editor (Doolwind, 2017; Wikipedia, 2017c). Among these, the Producer not only oversees the entire team, but is also responsible for the aspects of Software Engineering, including project management. The activities of the Producer are typically undertaken by software engineers (the titles assigned to these positions vary a lot: Engineer, Manager, Game Designer, etc.), evidencing the necessary presence of the engineer in a game development team. Without proper systematization during game development, even the best ideas will fail (Lemes, 2009).
This systematization must start before the production of the game, when the game design is defined and documented (Lemes, 2009): the GDD (Game Design Document) serves as the blueprint from which a game will be built, Sayenko (2015) has a great article describing how and why you have to write a good GDD; one of his tips for coming up with an effective GDD is to put just one person in control of it. From then on, it is the responsibility of the game designer (the engineer) to maintain the GDD.
It is clear that large game companies have specialized software engineers, but independent developers possibly do not. If indie developers lack a person skilled in engineering techniques, they will likely neglect engineering aspects. As stated above, without giving proper importance to such aspects, even the best ideas will not save the project. Therefore, here I analyzed the reality of indie developers in my home country, Brazil. I investigated: (1) if they have specialists in their teams to fill the role of the engineer; (2) if they actually use techniques from Software Engineering for developing their games; and (3) if they have defined and followed a GDD. It was hypothesized that the indie community in Brazil do not comply with the three topics above.
The first step of this study was a survey of the largest Brazilian independent game developer communities, which are mainly based on Internet forums and social media platforms. Only those groups on Facebook with 1,000 or more registered users and online forums with 1,000 or more registered users that are receptive (that is, accept the request to join the group in a period of seven days and do not exclude the search of the feed) were selected (Tables 1 and 2).
The second step was the preparation and application of a questionnaire (see the Appendix) to the groups and forums selected on the first step. The Google Forms platform was used for this, as it allows the preparation of online surveys. The questionnaire was semi-open, with objective questions of single and multiple choice, also counting with fields for (optional) further comments and explanations. The questionnaire was composed of 16 questions in total and was presented to the groups outlined in Tables 1 and 2. The third step consisted in analyzing, interpreting and exposing the collected data in a statistical manner. In this way, the initial hypotheses raised in this study was put to the test.
Table 1. Indie game developers groups on Facebook (last access: 03/Apr/2017).
Table 2. Online communities of indie game developers (last access: 03/Apr/2017).
RESULTS & DISCUSSION
The questionnaire remained available for the developer communities for 17 days, during which 35 different questionnaires were answered (without duplicates).
According to the data collected, almost 70% of the independent developers do not use engineering techniques (Fig. 4: Q2). In the circa 30% that do use them, the engineering methods cited are: Design Patterns, MVC (Model-View-Controller), MVVM (Model-View-Viewmodel), MVP (Minimum Viable Product), Scrum, Prototyping, Briefing, and Modeling with Diagrams. (It is not the objective of this article to discuss the different engineering techniques, but, as they are readily available online, I urge the interested reader to look them up.)
Figure 4. Percentage of answers for Yes/No questions. Question numbers are the same as noted in the Appendix. Q2: Do you use engineering methods and techniques in the development process of your game(s)? Q8: Do you or your team write a Game Design Document (GDD) at the beginning of your project? Q9: Do you and your team follow a system requirements document in game implementation? Q10: Do you consider it important to draw up a Game Design Document for your game? Q15: Do you consider using software engineering methods important in the process of developing your game(s)?
In 2013, Fleury et al. (2014) surveyed the methodologies used for software development in Brazilian game companies, noting that circa 25% did not use any methodology. The absence of software development methodologies was deemed worrying, demonstrating the lack of professionalization of this industry in the country. That survey focused on the actual industry (with a large number of respondents), showing that the problem is not something endemic of independent developers. In any event, it is a much larger problem in the indie community, even when current literature and previous research strongly advocate the importance of engineering methods.
Among those indie developers that do make use of software engineering, most of them (ca. 74%; Fig. 5) opted for not using agile methodologies. The so-called “Agile Software Development” are a set of principles for development based on the collaborative effort of self-organizing and cross-functional teams (Wikipedia, 2017a). Among those who do use agile methodologies, Scrum is the most used one (ca. 20%; Fig. 5).
Figure 5. Answers to Q13: Do you use any of these agile methods? Abbreviations: XP = eXtreme Programming; FDD = Feature Driven Development; DSDM = Dynamic System Development Model.
Another flagrant issue is the lack of a specific professional on the teams who is responsible for the engineering and documentation of the project under development (the Producer mentioned before). By the answers (Fig. 6), having an engineer on the team is exceedingly rare for independent developers. This position apparently is not deemed important by them, which may explain the rare use of Software Engineering methodologies in their development processes.
Figure 6. Answers to Q5: Which member(s) make up your development team?
This question can be better understood when we realize that most independent “development teams” actually consist of a single person. About 57% of the interviewed developers work alone, which might explain the usual absence specific software engineering skills, as most programmers are not specialized in this field. It also explains the anecdotal data on the large number of abandoned projects with exhaustively long production times. Things such as this can be estimated with software metrics, provided there is someone (the engineer, manager, designer, etc.) with the necessary understanding of Software Engineering (Pressman, 2010).
The elaboration of the GDD, as predicted, was also precarious: it is not made by roughly 50% of the interviewees (Fig. 4: Q8). Failing to elaborate a document with the specificities of the product at the beginning of the project can lead to several problems during the game’s development process. It is curious, however, that the importance of the GDD is acknowledged by most developers (80%; Fig. 4: Q10).
Similarly, the importance of using engineering techniques is recognized by most developers (ca. 70%; Fig. 4: Q15), even though only a third of those interviewed (Fig. 4: Q2) actually uses them. This data echoes the above-mentioned survey of Fleury et al. (2014) that evidenced the lack of professionalism by Brazilian game developers.
A common difficulty mentioned (by six respondents) is the dissemination and marketing of the product, which is a key factor, naturally, but one that can be addressed at the beginning of the project based on market risk analysis and estimates of the investments required for a future marketing campaign. That is, this is a problem which can be solved or attenuated by engineering skills. Other difficulties raised were the low investments and scarce incentive to independent development (eight respondents), lack of professionalism (three respondents), and lack of time to finish the game (two respondents).
From the data obtained here, it can be seen that Brazilian independent game developers still lack professionalism, especially regarding adequate methodologies. Curiously, this is recognized as a problem by the developers themselves. The alarming low usage of Software Engineering techniques also highlights the need for instruction and self-guided research on such methodologies.
Of course, that is not to say that all indie developers in Brazil are in this position or that a lack of professionalism permeates the whole industry in the country. However, the large percentage of developers to which these conclusions apply show that this is a real big issue and the importance of using engineering knowledge to manage and produce quality products cannot be over-emphasized. I hope this serves as a call-to-arms for the indie developers to review their position and start studying and applying concepts from Software Engineering. Citing Velasquez (2009: 30) once again: “[a] computer game is not just a toy, but a large and complex software project developed by a vast team of professionals” and should therefore be treated as such.
Fleury, A.; Sakuda, L.O.; Cordeiro, J.H.D. (2014) 1º Censo da Indústria Brasileira de Jogos Digitais. NPGT/EPUSP, São Paulo.
Lacerda, E.L. & Selleri, F. (2012) Um levantamento sobre processos de desenvolvimento de jogos para redes sociais. Proceedings of SBGames (XI SBGames, Brasília): 77–80.
Lemes, D.O. (2009) Games Independentes: fundamentos metodológicos para criação, planejamento e desenvolvimento de jogos digitais. Pontifícia Universidade Católica de São Paulo, São Paulo. [Unpublished dissertation.]
Morais, F.C. & Silva, C.M. (2009) Desenvolvimento de jogos eletrônicos. e-Xacta 2(2): 11 p.
Pressman, R.S. (2010) Software Engineering: A Practitioner’s Approach. Makron Books, São Paulo. [Portuguese (Brazil) edition.]