next »

[xrubio]

 

Hi everybody! I'm part of a tiny studio called Murphy's Toast Games. We are interested on creating videogames designed to teach stuff about science; please don't frown upon the suggestion that we create "educational games" because frankly we are not really happy with the whole concept of "games that are supposed to teach stuff but at the same time are not really fun". We are also avid gamers and our idea is that it should be possible to create games that are fun to play because game design and story use concepts from science. To summarize: we want to create real games with real science where science improves the game experience instead of blocking it.

Our first game was released 2 years ago and it was called Evolving Planet. It was a strategy game mixing science-fiction with archaeology that you can freely download it for ios and android (BTW we also released the code as open source).

We are excited to say that development in our second game has started. I thought that it would be interesting to write a development blog to explain the experience for 2 reasons: a) get feedback from the community and b) compare our own development with games that are not focused on scientific things. Let's start!

The game does not have a name yet but we definitely have a theme: the game will be a manager of palaeolithic peoples where the player will control a group of hominins struggling to survive. The main interface will be the camp from where you will send your Neanderthals or Homo Erectus to explore the landscape, hunt and gather resources, look for minerals or build weapons. The landscape will constantly change and you will have to come up with sustainable strategies to make your group thrive on a hostile environment.

This is the very first draft of the user interface we have in mind:



and here the first concepts made by our wonderful artist!



We decided to move towards a retro design so this is the final version of this Homo Pixelus:




We are currently discussing general game mechanics, artwork style and similar things. I have to say that this is the most difficult phase; it's complicated to come up with good designs when not a single line of code has been written! Next posts will cover some of these discussions,  new artwork and technical decisions. In the meantime feel free to ask anything you can think about, and thanks for reading!

[xrubio]

The first steps of a videogame development are mostly focused on decisions. What language should I use? For which platform? What type of artwork should we create? While these options may be changed on the future it is essential that you think about them and plan accordingly; otherwise you may waste your time and energy on dead ends.

I'm going to focus on the most technical component of the project as we were eager to set up the project and start coding some lines.

Release platforms

First, the target platform for our game. This is a game designed to promote scientific thinking and for this reason it should arrive to the widest possible audience beyond the most active gaming community. We decided to follow the same idea we had for Evolving Planet: to develop a game for portable devices using ios or android operating systems. Another advantage of this approach is that the game will be distributed through the digital stores so we will be able to do it without investing lots of times on this final step.

Framework

There will be a difference, though; Evolving's User Interface was designed to be optimal for tablets such as ipads or Samsung Tabs. Checking the statistics of download we realized that this assumption was wrong as a large majority of users played the game with phones. As a consequence this time we will design a UI for small screens and a portrait orientation.

This decision leads to the most important technical choice...what development framework should we use? Again, based on the experience of the first game we decided to continue with Cocos2d-x. There are several reasons behind this choice but the most important are:
1. It is open source and it is supported by an active community
2. The same code can be used to generate binaries for linux, windows, ios and android platform (plus other ones).
3. It is C++, one of my favourites languages.
4. It has a nice architecture and everything makes sense. It also provides functionality for extra stuff beyond graphics (audio, storage, threads...)

Reason number 2 cannot be stressed enough. Cocos gives me the flexibility to develop and test my code using any computer and then check that it works on my phone without changing a single line of code. This versatility speeds up the testing process by an order of mangnitude compared to other methods.

Development

I kind of hate the fancy IDEs with tons of options that I will never really understand. I code using Vim in a Linux environment and compile from command line. Cocos2d-x is perfect for this method as I can compile and run the game under Linux with a single line of code so the process is suited to my coding style.



Once the code is working I open the same project with the Android Studio IDE and generate the APK binary file that will be installed in my phone. It quite an efficient method that gets more complicated when working with ios, but we will get there on the future...

Version Control System

Last but not least I used github for the version control system. This is one of the main tools that any coder should learn to use. Git or similar version systems will help your life many times by keeping track of your changes, comments and issues. It may be designed for team development but I always use it even if I'm coding alone the entire project (as this may be the case).

Getting there...first build!

Once all these steps are set up we started with a skeleton application showing some sprites and basic screens (logo, menu and main play screen). Our illustrator Jaume Mayans supplied the sprites after working for quite a while on this first prototype as you can see in this video.





After a couple of hours setting everything this is the output with all layers in place. It may look like a very small achievement but my dev planning is typically based on short-term goals I can achieve on a coding session. Next week will be focused on game mechanics after some team discussions!

[xrubio]

Last week we created the basic project and showed some sprites. This small step boosts your morale because you see some code in action but once you arrive here it is a good idea to start planning your project.

We use the github platform for all our planning. I will try to explain how exactly our development process uses a range of github tools in case it can be helpful for other people.

Wiki

Github has a simple system to create a wiki page for a given repository. We use this platform as the basic design document where we will be discussing all our ideas for game mechanics, technical solutions, artwork, etc.



Let's put as example the initial implementation of one task: Hunting. After creating the webpage on the Home we start working on the different details and process so the team can discuss how to tackle the challenge.



This is a very dynamic format that allows us to rapidly discuss ideas and find the most suitable solution to model it. Once the design is more or less clear we will create one or more issues on the system.

Issues

Issues in github are a flexible way of managing things that need to be created/changed/improved in your project. It may be originally created as a bug tracker but in my opinion its simplicity makes it an excellent platform to set up goals ans tasks for the development as well. My approach to any feature is to split it on small steps that can be tackled in short code sessions and create an issue for each of them. Each of the issues briefly defines what needs to be done and is tagged with a bunch of colors depending on the type of feature (i.e. game engine, user interface, ios, android...). Every time you finish one of the tasks you commit the change and close the issue so you get a constant sense of achievement until you get the job done.



You can take a look at the list of Issues we created for Evolving Planet (over 300...!). Bug reporting for alpha and beta phases are also recorded here simply by using different color tags. One thing that is particularly important here is that you can automatically mention and close issues while committing your code changes so everything gets connected: design (wiki), development (issues) and code (commits).

Updates

The development cycle just described is rather simple and efficient and the best part...it works! At least for small teams as the ones I'm used working with. You don't get tangled on huge design documents and the links between designing and coding are rather direct. This week we worked on the concept of task that will be central on the game. From the main screen you will be able to start a task amongst a range of options (i.e. hunting, gathering, trading, looking for minerals, ...) and the decision will be based on your priorities and needs. We wanted to start with a specific one while understanding the type of software design that would suit the expected diversity of actions.

We chose Hunting as it will be central to any game about prehistoric hunter-gatherers (sic). Our artist was not available this week so we worked with basic sprites for all the Hunting screen (they are so terrible that I prefer to not show them to avoid any injury in your eyeballs). This served as an excuse to also start working on the World class that will contain all information on the state of the universe and your group, from the number and type of animals around to the profficiency of your group on different types of technology.

Summary

We also started collecting metadata from the development to see how the project grows over time. This is the state as of today:

• commits: 14
• lines of code: 1248
• num. files: 83
• open issues: 6
• closed issues: 4

[xrubio]

We are using this week of rest of our full-time jobs to work on the project. I will write just a quick update as we don't have a lot of graphic material to show because we have been working on the game mechanics.

tasks

As you read before the concept of the game is to manage a group of hominins hunting its way during prehistoric times. The group will manage to survive if they achieve enough food to survive and flourish. However, there is no easy prey and so you will need to organise its lifestyle based on a set of diverse and connected tasks:

• Hunt - This task will require tools such as spears to kill the animals and hand-axes to butcher them. Hunting will provide food and some materials from the animals such as bones
• Tool making allows you to hunt and other tasks requiring technology. Tool making needs a diversity of materials from bones and skin to wood or flint minerals
• Resource collection is needed to collect materials from different areas so you can make tools. You will need to send an expedition to collect these resources

We decided to create these 3 initial tasks because they form the basic cycle of resources -> tools -> hunting. However, other tasks will be gradually coded as develops progresses, including trade and conflict with other groups, fishing or gathering. You will need to maintain a balance between the different task if you want to expand the group on a sustainable way. 

events

The daily life of your group will be affected by randomised events. Every now and then 2 events will pop up on your screen and you will have to choose which one will occur. Every pair of events will have a similar impact as both of them will be positive or negative. One example of two events that may be paired:

• Too many wolves - The existence of large wolfpacks has decreased the amount of deers in the area
• Thief! - During the night one man has left the group with large amounts of food

Which one would you choose? By adding the events system we will introduce changes in the world where your group lives that will be based on the findings of the archaeologists for the specific period of prehistory.

artwork

The artwork is also slowly finding its way! We won't show the temporary sprites we are using right now because they would make your eyeballs go  but you can check this video where Jaume is digitising a hand-drawn hominin:
 




summary

Metadata as of today:

• commits: 24
• lines of code: 3015
• num. files: 150
• open issues: 11
• closed issues: 13

So yep...we tripled the lines of code in a week almost doubled the number of files, not bad! 

[xrubio]

We resumed our work on the project after some very welcomed Christmas holidays. Our month until now has been mainly focused on choosing the right artwork style for the game; it has proven to be quite a challenge!

If you remember we started using a cartoony pixel art style.



The reason behind the pixel art choice is based on workforce: there is only one person responsible for the artwork so either a) he focuses on excellent drawings or b) he focuses on excellent animations. It is a matter of choice on where do you put your main efforts; pixel art would theoretically allow us to generate good animations with less effort due to the limited size of the assets.

However, this limited size also implies that details are scarce. This was an issue because we wanted to show as much detail as possible of the different hominins (Antecessor, Heidelbergensis and Neanderthals). One of the main interest of this game will be the fact that all the stuff that will happen is based on scientific discoveries so this detail is important for us. How can you combine this detail with pixel art? We tried something like increasing the size of the heads but it didn't really work.




I mean, it could work but it was quite similar to the style of more popular games. Additionally, this style made the Neanderthal look like a dwarf so we looked for something else...what if we create pixel art that looks semi-realistic?



This was better but the details were still hard to draw. If you are thinking "what the hell is the red thing in his head?" it's ok...it should be a feather as Neanderthals wore them as personal ornaments such as this reconstruction...



Jaume switched then to a more realistic style where all these details can be easily seen.



After so much exploration it seems that we are on the right direction! We may create a lower number of animations but we are thinking on how to speed up the process with additional tools such as Spine. In any case, this is not a platformer so having a large number of animations is not that relevant (and specially if you get in exchange high quality artwork).

This is a comparative drawing of the 3 playable species in the game using this new style: Homo Antecessor (oldest hominins in Europe), Homo Heidelbergensis (rather tall and technologically advanced) and Homo Neanderthal (really tough people).



You can see in this video how Jaume transformed the drawing to digital and colored it.





...and here you can see an Smilodon or Saber-toothed tiger as a first sample of animals. This kitten will be more than a match to any group of hominins willing to challenge it.



That's all! We continued developing the code but this will be further discussed during next weeks.


Summary stats

• commits: 47
• lines of code: 4528
• num. files: 220
• open issues: 19
• closed issues: 34

 

[SchriefFighter]

Digging the art style you have for the title

[woodsmoke]

The prehistoric setting interests me. Three different species sounds fun. Good job exploring the art style. 

[whistlerat]

I think your latest art style is definitely the strongest, and I'm loving that sabretooth! Neat concept overall, I look forward to seeing it develop

[xrubio]

Thanks for the feedback! At some point I want to talk more about the different playable species and settings. The game will take place on different periods at the Atapuerca Mountains where the earliest human beings in Europe have been found.

We will hopefully have some new animations next week...we are testing the use of Spine but other suggestions are very welcomed 
 

[xrubio]

The game we are developing will have 3 playable species. Each of them introduces a different landscape:

1. Homo Antecessor is the oldest hominin ever found in Europe. The landscape will be a rain forest with plenty of resources

2. The Heidelbergensis will have a slightly tougher time living in a savannah; luckily for them their technological is much more advanced.

3. Neanderthals lived in the toughest environment where resources are scarce and most of the territory is covered by ice. On the other hand their technology and culture is rather close to modern humans.



This increasing challenge perfectly fits a game because it defines the progress on difficulty: a) the player will learn the game mechanics with the Antecessor then b) Heidelbergensis will force her/him to to learn new mechanics including hunting and finally c) everything learnt will need to be applied to the hardest scenario of the Neanderthals.

We have started by the most complex scenario: the Neanderthals. And here is the group that you will be leading!



The main screen of the game is the Camp where the characters are based. By touching them you will be able to perform the different activities required to survive:

Gather stuff



You will need to organise expeditions to look for basic resources, including crafting materials and food.

Make tools



Stone tools are the most important objects that Neanderthals left behind. We archaeologists have learnt a lot about these objects and for this reason they will play a major role in the game. They will be used for almost everything: from chopping wood to butchering animals.

Hunt animals



Meat was a very important part of the Neanderthal's diet. They mostly hunted large game such as deers, horses and even the might mammoth! But you will not only hunt for food; their bones, antlers and skin are valuable goods for making better tools.

Butcher



The animals that you hunted need to be butchered in order to get resources. This is quite important for these people because they could not move around bringing a mammooth carcass with them.

Move around



You will need to move a lot between different camps in order to find new resources and hunting grounds. But you are not alone; you will often need to fight for the territory with other groups of Neanderthals and frightening predators.

Innovate



You will need to improve your knowledge in order to flourish. These innovations will be costly but they will increase your chances of surviving. Their effects will be quite diverse as they will affect ecology, technology and culture.

Lead the group



This guy is your mentor. He will give you plenty of information on your goals and landscape. This is a way to integrate all information on a single screen where you can learn more about animals, resources and tools at your disposal.


These are the basic activities but we are planning to implement other ones such as Fishing, Scavenging and Bartering stuff with other groups. The unique twist of our game is that everything you will do is based on the knowledge we have learnt from archaeological discoveries. This also includes the animals you will hunt, the tools you will make and the clothes your group is going to wear!

Finally, an essential challenge of the game is to develop a sustainable strategy; if you hunt a specific prey too much or you stay too long on a territory your group will overexploit the land and you will run into trouble. To solve this puzzle you will need to balance the cost of moving between camps with the perils of overexploitation.

If you are interested on how Jaume draws these characters take a look at this video!






Summary stats

• commits: 83
• lines of code: 6008
• num. files: 225
• open issues: 13
• closed issues: 72

and... we got a working title!: After lots of brainstorming   the preliminary title we chose is: Ancestors: stories of Atapuerca

[xrubio]

Welcome again! It has been a long time since the last post...we have been working on the code and the interface, so nothing super exciting. On top of that we were rather busy with other matters (teaching, family, and you know, life!). In any case, these 6 weeks have been very intense and we finally got something that can be shown.

As you may remember the game will focus on the management of a group of hominins while they look for food, develop tools, brave the elements and control the territory. The 3 species (Antecessor, Heidelbergensis and Neanderthal) won't be available since the beginning but you will be able to unlock each of them by completing the scenario of the previous one. Once you finish unlocking the species the main menu will look like that:



We chose this almost metaphorical menu to reinforce the feeling of transcendence: these individuals lived tens of thousands of years before us but they were not that different to you and me. This is also a way of linking the main characters of the game to the player: despite the huge temporal leap they saw the same stars we can still see today.

Once you select one scenario you will get an overview of the camp. There will be several camps on each area as these people moved around following the herds and exploiting a diversity of resources. Each of the characters in the camp gives access to a different activity required to survive on the wilderness.



We had some fun working on the backgrounds. In the process I learned how to code shaders using cocos2d-x. which can allow you to code some cool effects such as outlining (when you touch a button) or blurring/focusing mechanics (when you touch on an activity).

For example, if you touch the guy making tools you will go to a new window with the blurred camp and a bunch of options for you to make. Each of the tools is useful for a different activity (hunting, butchering meat, cutting down trees, making other tools, ...). However, making them is not free: you will need some resources (e.g. bones, antlers, stone, ...). Additionally, most of the activities have a cost on food because you need to spend some time doing them. As you will notice, in this game nothing is for free!



One cool detail...the "make" button is the skull of the species you are playing on the current scenario. The screenshots were taken with the Neanderthals so it is based on the thick browridge that these guys had.




The implementation for the rest of the activities is almost finished, but the artwork is half-done so we will show them during the next weeks. We are also planning on publishing a couple of videos portraying the game in action. Additional mechanics are also implemented such as random events and the list of objectives for the game.

We are slowly approaching the feared alpha test! Our goal here will be to test if the basic game mechanics are fun, but also to find a balance between the time you spend on the different activities (hunting, gathering, moving, etc.). We don't want the player spending half the time making spears and then spending all of them on hunting a single mammoth!

Summary stats

• commits: 136
• lines of code: 8747
• num. files: 255
• open issues: 26
• closed issues: 110

[Fuzzy Branch]

I think you made the right choice as far as switching art styles. I commend the goal of bringing educational material to your game, and will be very interested to see how you guys incorporate that into the gameplay/presentation, since it can be a tricky problem. Keep it up and good luck hitting your Alpha milestone!

[xrubio]

Thanks! This is precisely our goal: how to create real games while at the same time teach something? The "educational" label is currently a synonym for boring so we are trying to do something different.

Our approach is that the integration of learning in gameplay itself is much more effective that long texts explaining how they lived: you will learn about their lifestyle because it is the only way you can beat the game.

As an example, why did they constantly move as nomads? In the game, if you stay too long on a single camp then the amount of animals and resources that you collect will slowly decrease due to overexploitation. You will need to spread your activities over different camps to avoid this situation.

Additionally, the game has plenty of visual cues and details providing additional insights, from changes on the landscape and the animals to the different tools they had or their body decorations (tatoos, jewelry, etc.).

I think you made the right choice as far as switching art styles. I commend the goal of bringing educational material to your game, and will be very interested to see how you guys incorporate that into the gameplay/presentation, since it can be a tricky problem. Keep it up and good luck hitting your Alpha milestone!

[xrubio]

We just uploaded a short video showing the first gameplay of the game:

[xrubio]

Game Over! (weeks 18-23)

Welcome to the development blog of Ancestors: stories of Atapuerca. We got some updates about the project; the scenario where you will take control of the earliest hominins that populated Europe is finished. This campaign is also the simplest and it works as a tutorial so we are almost ready to do some testing.

In the meantime, I want to talk today about a classical game design challenge: the game over screen.

We had a bunch of questions to answer:

• What does the player lose when the game is over?
• Can we integrate the game over with the game mechanics?
• How frequent should be the Game over screen? What difficulty should be appropiate to enjoy the game?

We thought a lot about the whole concept because the game is supposed to be designed with a wide audience in mind. It could be a class of teenagers in high school or someone that downloads the app because is interested on Prehistory. Or a gamer that just wants to have some fun so...the main question is: how to design a game that is a challenge for everyone?

The final design is inspired by other strategy games such as Into the Breach or Valkyria Chronicles. The idea is that every time you run out of food your game finishes. This is the Game Over screen and you see a summary of your actions during this play. However, you appear again with your food reserves full and the game continues. So, to summarize the process:

1. you perform some task that empties your food bar



2. game over! you see your stats



3. the game starts again with the same situation and plenty of food


The number of plays (i.e. generations) that you need to finish the campaign will be your score; the best score possible is to finish the campaign within a single play. In this way everyone will be able to finish the campaign. It will also be a challenge for seasoned players willing to achieve a better score.

The approach works well but we wanted to integrate it within the game. What does this game over really mean? How to communicate to the player how well or bad is he/she playing?

We decided to integrate it into the narrative of the game. If you run out of food then your group will have to leave the region for several years; when you start again it means that a new generation has come back to fulfill the goals you left behind.

Additionally, we came up with a cool idea on how to show this time line. A key concept of archaeology is that as you dig deeper in your excavation you will find older stuff. In esssence, an archaeological site is an accumulation of layers of earth and each of them belongs to a different period.

We recreated this dynamic in the game: every time you come back you will pan from deep underground up to the surface where your camp is located. This distance will grow as you have to migrate:

So, you always have some very old layers that you will always see:


Every time there is a Game Over then a new layer is added to the stack. The layer has some graphical references relating it to your game (bones, tools, etc.)y:


If you need to migrate lots of times then the number of generations will grow:


So the pan from the depths of the Earth towards the surface will get longer and longer


This solution also generates an interesting strategy: you may decide to run out of food performing some activities and migrate. Your group will receive a full food bar as a tradeoff for worsening your final score.

I hope our reasoning is useful to other game designers! A final note: if you decide to use a similar approach then make sure that the tutorial tells the player that the game over is part of the experience. Otherwise they will try to avoid dying at any cost and it will make the game really hard:


Next weeks we will test if this solution works or it needs some improvement!

Summary stats

• commits: 204
• lines of code: 12302
• num. files: 382
• open issues: 30
• closed issues: 152

[Zireael]

I love the art style and the theme.

I think you have a really good grasp of a game over screen for a game that spans multiple playthroughs. However, I have two nitpicks: the picture overlaps the letter L of Leader in the last screenshot, and the game over screen should somehow reinforce the 'this is NOT the end' message (some other heading than game over, maybe? "game over... temporarily" could do the trick.

Also, is the game localized only in English or are there other languages (from the Github screens, I gather you're Spanish?)

[xrubio]

Hi! Thanks for the feedback, much appreciated!

The overlap between image and letter is caused by the new font; it was created from scratch by the team so it still needs some work. Also, some of the artwork is also preliminary (specially the inventory items).

You are right that we need to emphasize a lot that the game over; another message won't harm, I guess! My worst nightmare would be someone leaving the game after seeing the game over screen just once.

Finally, the game will be published in English and Spanish but more languages may be added later; our last game was also multilanguage. and we realized that lots of people really appreciate the effort.

I love the art style and the theme.

I think you have a really good grasp of a game over screen for a game that spans multiple playthroughs. However, I have two nitpicks: the picture overlaps the letter L of Leader in the last screenshot, and the game over screen should somehow reinforce the 'this is NOT the end' message (some other heading than game over, maybe? "game over... temporarily" could do the trick.

Also, is the game localized only in English or are there other languages (from the Github screens, I gather you're Spanish?)

[xrubio]

Hello and welcome again to the development blog for Ancestors: stories of Atapuerca. After a very busy week making sure the game is playable we finally hit the alpha state yesterday.

Before that could happen we had to fix some problems of structure in the typical issue that arises in game development: you have an idea that seems cool on your head, but once it is implemented you realize that it does not fit with the rest of the design. These problems are very difficult to detect before you have invested a large amount of time on the idea, and once this is done you can either ignore the problem or discard a good chunk of your code (and a little bit of self-steem).

In this case the whole game was structured on one campaign per playable species of increasing difficulty. They would be introduced on chronological order so you would have to finish the Antecessors before starting the Heidelbergensis campaign and finally unlocking the Neanderthals. We started with the Antecessors but we realised that the campaign took a lot of time and this may not be suitable for a mobile-based game. Moreover, it made testing difficult given our very small team as the diversity of options was too wide to perform efficient testing. Finally, it didn't really contribute to the storytelling as each campaign was completely independent from the rest.

The solution we found was to change the structure of the game; instead of 3 campaigns we would have different stories or episodes focusing on different aspects of the game: the first one as a tutorial of crafting and hunting, then a second one introducing new mechanics such as innovations, a third one adding events, etc. This would allow for shorter and more varied game experiences. On top of that we came up with a meta-narrative that would link all the episodes and reinforce the whole theme of the game: each episode would be a story told by Sapiens about their ancestors.

I introduce The Storyteller:



Each night she entertains the rest of the clan explaining a legend of the people that populated the area and told through generations of humans. Environmental storytelling embeds details of this culture such as the ornaments of the old lady and specially the recent cave paintings found in Cueva Mayor, Atapuerca.




Once we changed this then everything seemed to fit into place! The theme, game structure, artwork and gameplay felt much more connected than before so we could focus on designing stories exploiting a couple of mechanics each time (e.g. crafting and innovations, or events and hunting, etc.). We can also add some interesting characters that will enrich each story.





Now we are facing the scary alpha testing where people will start playing the game. We are not sure what it's going to be the veredict as we need to engage two very different audiences: people interested on mobile gaming and people interested on archaeology. There is obviously some overlap but as we discussed on the last post this double goal has implications for the design of the game itself. In any case we hope to get very useful feedback and improve the game before the expected release in late August.

Here are some additional screenshots of the game that will hopefully wet your appetite. We will be writing a post asking for alpha testers in these forums the alpha passes Apple's review so keep in touch if you are interested!


The menu where each story is a different constellation


This is the event system; players need to choose one of 2 possible events (both of them being good or bad).



The hunting screen where you will choose a herd to attack and the size of your party. Hunting is so important in the game that it has its own minigame.

Next weeks will see how we create the rest of stories and integrate the feedback from the testing session.

Summary stats

• commits: 327
• lines of code: 15322
• num. files: 456
• open issues: 32
• closed issues: 239

[xrubio]

Hello and welcome again to the devblog of Ancestors: stories of Atapuerca. We finally got some feedback from the alpha testing and the past weeks we have been working on improving the game based on the comments of the testers. I have to say that testing is quite a stressful experience because it's hard to not feel overwhelmed by the diversity of comments that you may receive. In our case it's even more chaotic because we invited not only gamers, but also some archaeologists who never played a video game before. I mentioned in other posts that the impact of the educational purpose on game design is challenging and the feedback reflected this.

One thing that we noticed is that the user interface is fairly static. This is caused by the genre of the game as there are no real-time events and the things happening on screen only change if you interact with the user interface to make some action. Some people would find this relaxing but most players would get bored of it after some minutes. We decided to spice things a little bit by adding some simple dynamism to the user interface.

1. Animation of interface items

A cheap solution is to animate the appearance of user interface elements when you enter a new screen. This is rather simple to do and it makes the transitions between screens smoother (if you want to get some inspiration on this approach stop reading and go play Persona 5; it does not get better than this beauty!)



2. Sprite animation

The original idea was to animate everything on screen but this has not been possible due to the size of the team (we are 2 guys) and time limit (the game is part of a project that finishes within the next months). Jaume compromised by animating selected sprites on screens that would be regularly used by the player such as the map where the clan moves camps.



3. Screenshakes

The last idea was inspired by this awesome video of Jan Willem Nijman called The Art of Screenshake. It is certainly focused on an entirely different genre but the basic concept can be easily applied to any game: provide visual feedback to the user.

We implemented small screen animations for all the activities of the game based on the type of physical action that you need to perform to do it. This is the example for making tools.



We are thinking on the audio treatment as this would obviously benefit from some sound; anyway the effect creates a parallel between the player's input with the action inside the game.

Next weeks will be focused on polishing the game and designing the rest of the stories. Too much to do and too little time!

Summary stats

• commits: 359
• lines of code: 15918
• num. files: 451
• open issues: 30
• closed issues: 267

[Zireael]

I think it's better that you animate the important things instead of everything.