Devblog post #2

2D Art
3D Art

The past two weeks we have done a lot of work on the game. Unfortunately as with every business we also needed to do a lot of non-development related tasks, but we hope you are as excited with our progress as we are. In this post you can read and see what each member did and their way of making design choices on the game. Hope you enjoy it and feel free to connect with us through Twitter, Facebook or mail.

Wan Yie: 2D Art – Designing the hunting style

Previously we introduced an animal to the game indicating that the player can hunt. To hunt means there is a variety of hunting tools present in the game for the player to use. However, in Survive & Thrive you’re not forced to hunt. In fact, the game aims for survival in the nature as a whole instead of just specifically fighting predators or prey. Therefore we knowingly chose to emphasize the aspect of scavenging onto the designs, which means that any warrior-like weapon is out of the question.

The environment and culture in the game obviously indicates the traditional ways of life and that it happens in an age where technology has not yet developed. With that said, it is safe to say that the tools in the game must start out rather humble. In a way where finer sources such as iron or steel does not take part. Perhaps that we will implement sources such as metal or iron into tools later on, but to start off we will focus on sticks and stones.


Before we dive into designing the tools we first need to understand the world we use it in and what it will be used for. Should the environment be in the snow, then tools such as axes should have a pickaxe property on the backside of the head, which can be used for ice climbing or to hew frozen caves for example. Should the environment be in a desert, then tools such as a bow will unlikely be present as there is a lack of wood. Let alone wood strong enough to be bent without breaking.

For functionality, the tools must emphasize the aspect of scavenging as said earlier in the article. This will also be a deciding factor for the style the player would probably hunt in. For example; Large axes won’t do very well when throwing. It doesn’t have a great range as it is far too heavy to be thrown for the character, but its strikes are likely to deal a stronger blow. Smaller axes will strike a relatively weaker blow compared to a larger axe, but can be used for many more things than just fighting. In the end, when traveling you’d want to take something of lightweight anyway. Which brings us to a much needed attribute; the tool being handy.


As for hunting we chose a bow because guns are obviously far too advanced. And since the bow must look technologically underdeveloped, we made sure that the bow will get a traditional appearance. Originally a bow was made from one piece of wood and would be held in a bent position by a string holding onto both ends. (This technique is still used till this day!) Nowadays there are bows such as recurves and compounds. These however would look far too advanced, so we excluded these from the designs.

The art department discussed together as how the first bow has to look like. In the end we decided that shape had to be gentle yet distinctive. Any curve that is overly exaggerated would make the appearance seem too aggressive. The bow as how we designed it now is eyeing rather calm, additionally it looks like it is firm enough to shoot arrows. However, the bow alone looks really boring. To fix that we can just add features that resembles the culture of the character. Too many details on the bow would defeat the simplicity of its traditional appearance, so that should not be overdone!

Back To Top

Jeen: 3D Art

Hi, Jeen the 3d artist again. You can follow me on Twitter @jeenvis or contact me at: Today I will be talking about the way to portray plants and basic lighting setup.


The plants and trees were already in production, but still very basic. And some of the plants really looked plain or generic in a bad way. Wanting to fix that I’ve been looking at the reason why they felt so plain.

What happened:

After giving it a second and third look, I started to realise that the old plant models did not have any identity to them. They were just being there for the sake of being plants. Because the models weren’t interesting enough the environment itself didn’t look that appealing. I wanted to change them, clean them up and make better versions. And so I did, as you can read down below.



(Left model = old, right model = new)

What I did wrong: The old vern model was to thin and “weak”. This made it look less “joyful” and less strong. The silhouette is too complex and the model isn’t easy to read creating a disliking in the viewer’s eye.

What did I change: I made the leaves bigger and less curly, making it a solid silhouette that’s easier to read and a stronger looking plant. Also I added some details to some of the leaves making it less symmetrical.



(Left model = old, right model = new)

What I did wrong: I realised that the eggs from the candlegg plant were detailed but really hard to see. It wasn’t visible in the silhouettes and thus far not seen if a person wasn’t paying attention to it. When adding polygons you should always be sure to make them count.

What did I change: I made the edges bigger in contrast exaggerating the pine cone-ish shape of the eggs. Also the placement of hard edges were needed to make it more visible. The small shift of the candle piece of the plant also make it less symmetrical, thus more naturally.



(Bottom models = old, top models = new)

What I did wrong: Even the stones could use a bit more love. Although they weren’t “wrong”, they weren’t right either. They felt to generic, like a lump of dough laying around. Nothing indicated that this object was a hard object that’s tough to break.

What did I change: The silhouette was hard to change because the stone are bound by the shape of how people expect stones to look like. But choosing certain edges to be hard and soft is a well played strategy. These group of hard and soft edges create the illusion of the hard surface from the stones.



(Left model = old, right model = new)

What I did wrong: The old palm tree looked way to messy at the top. Especially the silhouette of the leaves were way too busy and it was hard to see a solid shape in it. While trying to make branches I accidentally created weird looking leaves that just appeared to be off.

What did I change: The leaves were to off looking to iterate on, so I deleted them and started over. I created leaves in the same way as the verns were created. This made the silhouette easier to read. The normals of the bark are made harder to attract more attention to the small rotations it contains.

Tip of the day:

Modelling and games (when stylized) are just like a theater play. You’ve got to exaggerate certain parts to make it more interesting and easier for the audience to understand what the object is.

Back To Top

Daniël: Animation

Hey guys, Daniël here. Last time I left you guys with a Main Character that could walk, run and Idle.

This meant that you as a player were able to walk around in the world on two different speed rates and stand still without actually being completely still.

These past two weeks I’ve been working hard on several things. Firstly I made the foraging animation which enables you to collect the food you need to survive!


Secondly: I spent most of my time building the animation skeleton for the deer. Due to several mistakes and hiccups this took way longer than expected. Albeit unfortunate for overall progress it was a very good learning experience for me as an Animator and Rigger.

My first rig had too little key bones and some of the ones that I did have were poorly positioned. Since the requirements of the rig were that the Deer needs to be able to bend over to drink water and eat grass, it became clear that the rig that I made wasn’t cut out for it. The skeleton needed extra bones in it’s chest area which would be used to rotate the bushy hair back so that the hair doesn’t get swallowed up by the rest of it’s body.

Alongside this there was some miscommunication on how the creature’s legs were supposed to bend. All of this combined made us go back on the Deer model and rig. Which meant that I had to redo most of my work.


When I received the updated model I was glad to see that I was able most of the current skeleton. The main work that needed to be done was moving around several bones to their new home. It took me some thinking to figure out the solution to the stretching chest issue but with some testing I found the best way (for me). I decided to add extra bones in the chest area with each their own controls. With these new controls I am able to rotate the chest backwards when the neck rotates forwards. This allows the deer to keep its dominant hairdo where it needs it to stay in charge.


Over the course of two weeks I’ve kept adding several controls and updated already existing ones when I needed the function to be more than what it already was. My current control setup and rig looks like this.

Finished Rigging

With this I can hopefully animate all the motions a real deer can and would do.


Once I was partially content with the rig I had, I started the first animation: Walking. In these past two weeks I have redone this animation more than 10 times just because we as a team weren’t that happy with the result.


The main reason for this was that I had a hard time grasping the motions from the reference I used. It took me a lot of trial and error but now I can safely say that it’s finally getting to a point worth sharing.

The plan for the next few weeks is to finish the walk animation and work on several others. Which include: Running, Eating, Alert and Death.

Back To Top

Neander: Programming – One step back two steps forward

These past two weeks I have been working on refactoring some of my code to make it more efficient. The first thing I took under construction was the item system, which had some unforeseen inefficiencies. I also did a lot of work in the player code wise and animation implementation wise. After these refactors were done I started on a new feature, the shooting of a bow so we can get some meat to eat. To make this feature a whole I also needed to create logic for dropping and gathering items, which I did.

Refactor: Item System

The system, in the way that it was before, returned a reference to the prefab instead of returning an instance. I changed the function for getting items out of the database so that it correctly returns an instance. As a challenge to myself I wanted to make assigning a type to created items more efficient, and by doing so add a unique ID.

Before we used to use an “enum” with unique names and values for every item. This worked fine for a few items, but now that we added more than one tree to the world- this dropdown of names would get disorganised. Since the enum is not sorted and doesn’t know which entry is a part of a group of items. To make this more efficient I made a menu that is accessible through right clicking on an item prefab. When this is done, a menu will appear, with all the different categories of items as a submenu and when hovered over this it will show all the items of that category. This way it is super easy to find and assign a type to newly created items. By doing it this way the the implementation of new items can be done by the modeller themselves so that I can start on new features instead.


Refactor: Main Character

For the main character I made some changes to how the code is structured. Before I had all the code for the main character in one player script. But after adding more and more functionality it became cluttered and hard to find specific things. Therefore I made four “handlers”: The movement handler, animationhandler, actionhandler and an inventory handler, with all having their own specific functionality. This way I can easily track where my code lives and if there should be a problem in the future, it will be easier to debug. It took a bit of time to change this, but in the end it will be more efficient and manageable so it will have its payoff.

Feature (Being implemented): Archery

For this feature I needed to do some research. First of all I needed to know how arrows behave and how people stand while shooting a bow. So that’s what I did. In my final implementation I went with a very basic but adequate implementation.

When the player presses the attack button the bow will start a timer that is set to the time that it takes to tighten the bow to its max. If the button is released the bow will shoot an arrow. The velocity at which the arrow is fired is based on how long the timer was running. This way if you hold it long enough, it will shoot far. When released prematurely, it won’t shoot as far.


To give the arrow a correct path it calculates the gravity for the arrow, by using the following calculation; gravity = velocity * Mathf.Sin(rad) * t – 0.5f * 9.81f * Mathf.Pow(t, 2f);. This calculation will make the arrow drop over time based on its velocity and the angle at which it is shot. This all works fine, but I still have to do some work on the triggering of the animations and aiming the bow. Then we also need to determine if we are going to allow walking and running while using the bow. But luckily we have some time left this sprint to make it ‘final’.

Feature (Being implemented): Gathering

Another feature I started this week is gathering of dropped items and dropping these items. To do this I made a base class between the item class and the child classes so that all droppable items have this functionality. Then I made a temporary inventory for the player so I can test the gathering system. The actual dropping of items is done by the thing dropping the item, like the Greydeer. Picking up the item is done by shooting a raycast from the mouse position. This has to be changed later on because when using a gamepad, we can’t use the mouse position. I think I will be doing the gathering by shooting a spherecast from the player’s position and then add all gatherable items to a list so we can check which one is closest to be picked up. I will try this and see if it needs more attention later on. The actual dropping of items from the player’s inventory will be implemented when the inventory logic is in place and made visual. For now I will keep it to a testing implementation.

Feature: Camera Rotation

To top it all of I also made a camera rotation system so that you can get more overview of your surroundings. I will not go into detail because it was a minor thing, but in my opinion it adds a lot.


Back To Top