Devblog post #3

2D Art
3D Art
Animation
Programming

We’re back once again with an update on Survive & Thrive. A lot has happened since the last post and we are happy to share our progress with you. And as always please connect with us through Twitter: @FourNomadsGames or Facebook: FourNomadsGames and share your thoughts and questions.

Wan Yie: 2D Art – Food Sources

As expected in any RPG game, you can find lootable items. The first thing we wanted to be implemented was the food source since it is an important aspect of the game. We chose for a system where you’d be able to see the items on the floor upon a successful hunt of an animal or when you drop items on the floor. Obviously it’s important to choose the colours and shapes wisely as it should be recognised within just a brief glance.

We thought that the flora in the game should have a slight uniqueness in their appearance so that the world will appear much more as fiction rather than realism. For starters, it is important to make items, with what you can interact with, stand out from the environment. The first environment we start out with is green with a hint of blue. So we choose purple and red for the items on the floor in contrast to the environment.

Blogpost_03Fruit_WY

The first piece of fruit we designed is one that was inspired by a durian, a pineapple and a banana. Can you find the resemblances? Anyway, it’s hard crust protects the rewarding fillings that could satisfy an empty stomach. (Or at least, that’s what we’d like to think.) The tree in which it grows is large and tall. Should the tree drop the fruit, it’ll have a much greater chance to break open for the animals to eat, resulting that the plant can reproduce on another location, rather than next to the tree it came from.

The first ground plant that is collectable from the floor is a mushroom. To make it stand out from the floor, the cap is made red with smaller cyan freckles that will glow in the night. (Perhaps signifying that the mushroom is poisonous. We haven’t decided on that aspect as of yet, but we will discuss that in the future!) Upon closer inspection you can see that the stem of the mushroom is spiked with thorns that have the same colour as the grass, making it harder to see the danger. This is so that smaller animals will have a harder time to scavenge it- allowing larger animals to take it to a much greater distance.

Blogpost_03Mushroom_WY

We did not think it was relevant to make the piece of meat as unique as the flora, so we kept it as recognisable as possible. To most common symbol of meat is a chunk of muscles from the thighs. There is not much to say about it other than it had to be made anatomical incorrect on purpose.. Enjoy the visual!

Blogpost_03Meat_WY

Back To Top


Jeen: 3D Art – The Bow

Model

For Survive and Thrive we needed a bow to hunt on the ‘Greydeer’. The bow needed to look simple enough to be made by our character in the wild. A second and equal important thing is that the character will run through forests, so the bow can’t be too big because then it will get stuck behind tree branches and other things. A third thing is the string, this object must be modelled in a way that it’s able to stretch without deformations.

Rig

For this sprint I was interested in making a rig and animation for the bow. This way I will be able to communicate better with our animator in the future, for then I understand his pipeline better. I started the rig by thinking about what the purpose of a bow should be. What does a bow do? It shoots an arrow thats for sure, but how? The easiest way is to say that the string stretches and pinches on the point where the hand pulls it. But when pulling a string this way it creates a lot of force, which makes the bow itself bend a bit. This is important to visualize the power of the shot.

BlogPost_img2_17-11

Animation

When I started the animation there was  a big fuzz about where the arrow would come from. We didn’t want to let the character grab the arrow out of his “inventory” bag. The arrow would be bigger than the bagg and it would look off. Also we wouldn’t be able to show the player how much arrows he/she has. This would be able when using a quiver. But that just started a second discussion. What kind of quiver? You’ve a lot of different kind of quivers and choosing one is a choice you can’t take too lightly. We started with the idea of using the basic back quiver. But after some research I found out that the back quiver is really bad for hunting because of it’s position, it will easily get stuck behind branches. Besides that the back quiver makes a lot of sound when equipped during running. This is really counter productive if we want to use the bow for hunting.

This is why we chose for a side quiver. A quiver equipped to the “belt” and hanging down along the upper leg. This one makes less noise and won’t get stuck as fast as the back quiver. It’s also easier to grab an arrow from the side quiver, because the user needs to raise it’s arm all the way up using the back quiver. After deciding the quiver it was time to create the animation.

I made a mental storyboard consisting of the actions needed to fire an arrow.

1. Grabbing an arrow.
2. Holding the bow in front of you so you’re able to grab the string and put the arrow in front of it.
3. Pulling the string backwards, building up force in the bow.
4. Holding the arrow next to your eye to aim and hold the string bended.
5. Releasing the arrow.
6. Impact of the force on the body.
7. Getting back to a neutral pose.

These parts need to be fluently overflowing on each other. Therefore creating one motion consisting of multiple movements.

BlogPost_img3_17-11

What I found really important in the animation was the knockback on the upper body when releasing the string. This is a simulation of the power released when the string is released. Without this the arrow would look less powerful.

Back To Top


Daniël: Animation – Greydeer

Good Tuesday to you all, Daniël here again. Last time I left you guys with a Greydeer that had the ability to walk around and thus giving the world a little depth. The deer would not just slide around anymore but were actually starting to come to life. We also added the foraging animation for our main character.

TempDeath_Edit

This period I made sure the Greydeer can be hunted down for food so that you as a player can stay alive longer. The death animation that I made for the Greydeer is not going to be the final version, it’s a placeholder animation and will be replaced with something more realistic in the future. But it will work for the time being.

GrazingNew_Edit

Whilst it’s important that the player gets fed we shouldn’t forget that the Greydeer needs food as well. So I made a grazing animation to make sure the little guy can feed himself. I split this animation up in three different parts.

Start Eating: The Greydeer stops and moves his head towards the floor with the delicious grass.

Loop Eating: It starts eating left and right and chews whatever he obtains. This part can go on indefinitely. The time the deer will take will be randomized to make sure you as a player won’t see two different Greydeer start and stop everything at the same time.

Stop Eating: Once we tell the Greydeer to stop eating it will get back up and look around before going back to his Idle state.

To make sure that you as a player will be given an incentive to sneak around the Greydeer as it will now be able to run away from you. The animation contains a start-up and a loop and is not entirely done yet. It will get polished up in the coming weeks.

Running_Edit

I’ve also split up the tail animations from the regular body animations to give that extra piece of randomness and liveliness. The tail animations can be played on any other animation and will be played at random intervals.

The plans for the next two weeks are to give the Greydeer an alert animation to let you as a player know when it notices you and will start running away. Polish the animations that are already there to make it more realistic and possibly work on a spear-throwing animation for the player. Have a good one folks, see you next time!

Back To Top


Neander: Programming – Performance and Iteration

The past two weeks I have been working on a lot of random programming tasks, which were not even planned in our SCRUM system, sorry Jeen :p But on a serious note, I made a lot of progress on the ‘visual’ side and on the background side.

World Issues:

As a side project I made a quick island generator which I used to generate a world for Survive & Thrive (for details, find me @MrGiljam on Twitter). But after implementing the map we found a problem with the size of the world. The problem was that when a certain threshold on one of the axis was reached the camera would go mental and start jittering like crazy. Out of experience I knew about floating point issues on large numbers but these problems were occurring at around 400 units which should definitely not be happening. A quick fix was to offset the map by half on the xz plane so that the center of the map sits at the (0,0) point. This was not really a fix but it takes longer to go over the threshold so it helped a bit. Another solution could be to move the entire world around the player instead of the player through the world, this would be a lot of work so we decided to put this off for a while. After not paying attention to the problem for a while I started work on other tasks and when I came across the camera I started to tweak some settings to change the render distance and clipping planes and there was the solution! When I changed the near clip plane on the camera to be just a bit larger, all problems with jittering were solved. So I slapped myself in the face and reminded myself to never forget this again.

P.S: All these artifacts were never apparent because we made use of an orthographic camera before. But after playtesting and a good design discussion we decided on a perspective camera and thereby gaining some bugs. The change was a minor one code based, but on the visual side it was major.

random_islands

Vertex Colors:

After analyzing the performance I came to the conclusion that we could gain a lot on the rendering side. The three light setup was taking up around 40 fps so I changed it back to one light with shadows and the difference was major. This means we have to find another solution to make the game as beautiful as it was with full lighting but by using a good shader or image based lighting we can make that happen.

After changing the lighting I also saw that the amount of draw calls was way out of proportion, it sat around the 5000 point, which even on a good pc isn’t that optimal. To fix this I made a vertex color shader and baked the colors into the foliage models themselves. This way we only use one material and now the draw calls are around 100. Which in my book is a major reduction :).

Vertex_Paint

Archery:

Last blogpost I wrote about the archery system I stared on. The art side had some setbacks so art wise I could not yet implement it, but on the programming side I made some progress. First of all, shooting now works on both keyboard and mouse and controller input. When using the mouse I first used ray casting to determine the shoot direction, but here the issue arose that when you have your mouse on a tree it will register that point so it isn’t that accurate and sometimes it would go just past a collider and rotate a lot in a short time. This was not ideal. I could have ignored all the colliders but the ground collider but I chose to use a plane raycast to determine the direction and this works better than I thought.

Further I tweaked the values of the bow and the arrow to be more realistic and have a better feeling. The system is almost done and when there art is implemented and the animations are correctly triggered it should be pretty satisfying to shoot Greydeer.

Target_Practice_Edit

Harvesting:

In between tasks I worked on the gathering mechanic. This is now fully implemented in a basic way. This means I will come back to give it some love but for now all things that are dropped can be gathered and will be put in the inventory of the player to be used later on.

Back To Top