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