Valleys Between is an environmental puzzle game, where your goal is to grow your world for as long as you can while protecting it from threats that will damage its health.
When we started designing Valleys Between we wanted to explore ways to get people thinking about environmental issues, and while the game has evolved during the game development cycle, the core themes of the game are still there. While we considered real world ecology and nature, we realised early on that to create a fun and engaging game we would need to take inspiration from them without being too literal.
One of our goals is to create a strong bond between the player and the world they’ve created, and one of the ways we do this is by allowing you to literally shape the world with your fingertips. Players only have the ability to swipe up or down to interact with the world, but small actions such as pulling a tree up out of the ground can actually have a big impact. Much like the real world, one action isn’t always enough to solve larger problems but a group of small actions can result in a big change.
Many of the games mechanics are inspired by nature, though in a simplified or abstract way. This allows us to craft gameplay that’s enjoyable and relatable without ever straying too far into something that feels completely at odds with reality (at least in most cases). With that in mind we had two important rules that guided our design:
The game is inspired by nature, so the environmental theme should always be present while never overpowering or distracting the player from the gameplay.
We won’t sacrifice enjoyable gameplay for the sake of keeping something too realistic or similar to how our real world works.
These rules allowed us to find a balance between fun and relatable mechanics that are easy for the player to understand. When designing mechanics we often started from an ecological concept and explored how we could distill it down to base elements to see how they could work well within the game. The best way to illustrate this is to look at the primary mechanics in Valleys Between.
At its core, Valleys Between is about creating a thriving world. The first step to doing this is to create an environment where things can grow, so the first move a player makes is to create water tiles in their new world. Water makes all dirt tiles around it turn into grass, and trees can only be planted on grass. To plant a tree, the player pulls up on a grass tile and essentially plucks a fully-grown tree out of the ground. While this is clearly a few steps removed from reality, it feels close enough, and this familiarity helps create a stronger connection between the nature presented in the game and what the player expects from nature in the real world.
Trees that are next to each other can be combined to make a forest, which grows your world by adding a new row of land. In this way, the base relationship between water and trees are shown as being critical to growing a world. Groups of forests can be further combined to make a house, which introduces humans as part of the ecosystem in Valleys Between. While this is an incredibly simplified representation of nature to a few small mechanics in Valleys Between, it’s part of what makes it feel environmentally rich.
The game wouldn’t be very fun without something challenging you, so we decided to introduce the two sides of human influence on the environment. The first is a positive influence of creating a house by combining trees which helps your world grow and expand. However, as your world grows, we also introduce a negative influence in the form of factories and other man-made objects. Factories threaten the health of your world and they can spill oil to surrounding tiles if you leave them for too long. While there isn’t necessarily an easy action to fix things these things in our world, we wanted players to want to protect their world from these threats even if they can’t stop them from occurring. We also found in early playtests that people became very attached to the animals that wander their world, and this helped them feel connected to it, so we decided to tie these concepts together and have animals act as the primary protectors of your world. Animals wander throughout your world, and while you can influence their path, you aren’t able to control them directly. You can choose to use them to nurture and enhance a specific area, or use them to convert a factory to something that won’t damage the health of your world. Once you’ve used an animal, they fall asleep for a period of time so the player has to choose when to nurture and when to protect their world.
While these mechanics may seem to be quite a stretch from the real world, we’ve found that by taking inspirations from nature rather than literal representations, we’ve been able to craft an enjoyable game.
ABOUT THE AUTHOR
Niamh Fitzgerald is a producer and game designer at indie studio Little Lost Fox, based in Wellington, New Zealand. She organised the New Zealand Game Developer Conference in 2017 and 2018, and likes to combine her love of travel with game development by getting involved in game developer events around New Zealand and internationally.
 Released in 2018 by Little Lost Fox. Currently available for iPhone/iPad and coming soon to Android. Learn more at http://littlelostfox.com/
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.]