Farquest

We've now decided a name for this game and that is Farquest. We also decided to have a break from combat and focus on other things, such as, other gameplay elements. I'm going to focus on optimizing the game for now as I noticed that the frame rates have been dropping a lot since I last worked on the map generation.

One optimization I've now made is polygon merging, biggest challenge with this was in the shader as I could not use wrap mode because all the textures are in one texture. So I created a shader that does the "wrap mode" differently, I injected the texture repetition count to UV, it will lose some quality but not enough to be visible (I can notice it if I look at a cube closely). Otherwise the polygon merging algorithm is very simple as you can see on the picture below.

Another "optimization" is multithreading, I did not want to do this one but I could not get the chunk generation faster. I divided the chunk generation to multiple threads and a part of the chunk mesh creation as well.

Oh and we created a twitter account https://twitter.com/FarquestTheGame if you wish to follow us there, we will try to update there more often with smaller details and pictures and whatnot.

Speaking of time flies...

So.. yes, hello, hi. For clarification I did not forget this blog, I was just hard at work, honest. But in all seriousness I have been at work this whole time, working on combat... which has been interesting and frustrating, mostly frustrating. The hardest part in this whole thing was making animations work in game, as this combat is very animations based. If a character is stunned and the stun animation does not exit early or at all it will break the combat as the character will be in an infinite stun lock. Most of my time was used in fixing these kind of problems and trying to crowbar unity mecanim to work the way I want it to (like animation transitions and blending), as well as trying to balance combat to be fun and engaging. While I was busy doing all that Samuli was hard at work providing me with new animations, concept art and modeling and texturing different armor parts.

Below I have a sort of a video compilation of all the progress we've made these past months on the combat and at the end what the combat looks like right now.

You might have noticed that there were only two types of combat, fists and sword and shield, we decided that the sword and shield will be our main focus at the beginning and then use it as a template for the other weapon types. The combat has also undergone a lot of change in how it functions, as we want it to be fast paced and responsive.

I also created a wind shader, my very first displacement shader, for the trees and grass

Time flies

Well time really flies and I almost forgot for a second time to write an update on the project, we've been so focused on creating combat for this game that it has taken most of our the time, there has been some hiccups with designing combat but all in all it's been heading in the right direction.

Currently the combat is still being created but is still missing animations and mechanics as well as some AI functionality, you can fight and defeat your opponent but it is still too soon to for it as the combat is too repetitive or easy.

Demonstrating ragdoll physics

Samuli while also creating animations for the characters has been creating armor parts and other clothing, we are also thinking of using external assets for creating facial hair or fur.

I'll update this blog once I have some decent footage of the combat to share.

Distorting time for a new direction

So we've decided to change the course of the project temporarily to create something smaller. We are using a lot of things that we've already created, but the combat and things the player will do in the game will be different, we will however continue the base project after we've completed this shorter one.

So what do we have planned? we are creating a survival game with quests and crafting, the combat is action based and there is character progression based on what the player does, very similar to the base project except for the combat. We're using the map generator for this as well.

We've been designing a lot of things and have created a timetable in which we hope to finish a demo of sorts of this game. Currently we are working on combat (fists for now). I've created a character in Unity's mecanim using the animations and character model that Samuli created, currently it has running, jumping, idle and fist combat moves. I have to say that using mecanim has, at times, been a real pain in the ass.

While testing we noticed that we could only have 40 characters at the same time before the fps starts dropping below 60, the reason for this was that there are a lot of seperate parts in the character model and each has a skinned mesh renderer, so I've began created a skinned mesh combiner so we can have different armors for different body parts.

Housing part 2

The house system is in a state that it can be used but it took quite a while and the rules with which a house will be built changed quite a bit, instead of creating the walls first the floor will be created first, then the walls and after that the roof, I also removed the levels button and instead players can just created high walls and add a floor to different levels, so why all these changes? well for one I didn't want to restrict players and adding more levels from a button would mean that only a certain wall height could be created and that seemed too much of a restriction and just complicates the programming unnecessarily.

Automated tools have also taken some of my time and some of the tools I will be creating later as it just seems too much work and I really want to focus on gameplay after the greedy meshing.

The construction GUI has also undergone some major changes as we forgot that we need to add other types of buildings and constructions to the world beside houses.

I've also been able to identify rooms automatically by using a flood fill algorithm, it starts filling above every floor cube and while it fills any found floor cubes will be removed from the check as they would just flood the same space unnecessarily, once a space is filled and it's closed inside walls and such it is defined as a room.

I also created RLE compression so I can compress the houses into a smaller size.

Housing

The house editor which I mentioned in Designing, optimizing and moving forward is coming along well and I have already added quite a few useful tools to it, there are a few missing features like the rules which the house should be created with.

After I've created the editor version I'm moving on to creating it for the game as well, after that I'll be focusing on greedy meshing.

Samuli also has almost finished the building GUI for the game and it looks awesome.

I've modified the biome editor slightly, we can now select which trees appear on different heights.

Before the end

I changed the orthographic camera to perspective as you can see in the above video, we decided to do this because the sense of depth was necessary and we might need to move the camera closer to the character in places like caves.

I also created multiple arrays of vertices/tris/normals/etc which will act as buffers for when I'm generating a mesh from chunks, this will reduce the amount of garbage that would have otherwise produced by the temporary mesh arrays, the only downside with these buffers is that they will use up a small amount of memory. Of course this could be avoided if I could just create a single buffer of each vertices/tris/etc and give it to unity's mesh class with a length parameter but I can't.

PS: Happy new year!

Designing, optimizing and moving forward

The new cube creator is finished for now, I will be adding more options and features to it later.

I haven't mentioned anything about greedy meshing and there's a good reason for that, you might have noticed that there are several different textures near each other making the greedy meshing very small and not all that useful, the other problem is that I have all of the textures in one atlas so repeating a certain texture would be problematic because you can't overflow the uv coordinates in an atlas so that the texture would repeat, so I had to created a shader which could repeat a texture inside an atlas by adding a certain amount, let's say 512, to the uv coordinates which would tell the shader how many times the texture would repeat, after that it would be just a few calculations to determine the current texture index by just dividing the uv by 512 after which we can get the actual uv coordinates for the certain part in the mesh.

While we can now repeat a certain texture it still does not remove the problem that we have multiple textures near each other, for that I would just need to create a new atlas and combine textures in a 2 * 2 texture in every possible combination so I can create 2 * 2 * 2 size cubes with one texture that has 4 different texture combinations for each side instead of 1 * 1 * 1 with one texture for each side.

There might be better ways to do this but I can't dwell for too long in optimizing the terrain generator or it might become a never ending project.

Me and Samuli have been designing crafting for the game and an interface for it and it looks great.

A mockup of the crafting interface.

I've also been creating a house editor for the game, we are going to make preset assets for NPCs, players can create custom houses in the game but they can also use presets as well. A house will be created in 3 different stages, first a player will place walls for the house after which he can place the floor or the roof or even more layers, after the house is designed players can predetermine what furniture the house will have before building it.

Terrain facelift in progress part 2

I've almost finished the new cube creator, only a few features are missing from the biome editor, but already we have made some very interesting and good looking terrains.

As you can see in the above image, we can edit the size and heights as well as what cubes will be generated to different heights, I also got the sub-biomes working.

Above image is a sub-biome of grasslands.

Desert biome and its sub-biome

Samuli also finished a new version of the 3D character model which is in the game already

We are continuing on adding more biomes and I'm leaning towards working on the gameplay mechanics.

Terrain facelift in progress

I've been recreating the cube creator as it lacked some features and it occasionally gave unity some problems as it started reporting errors of null objects being synchronized or something along those lines, anyway the new unfinished cube creator will make the map generation so much more flexible as the new features to the biomes and the new sub-biomes will allow broader range of options to the map generator, with it I can generate much more realistic and unique terrain.

As I mentioned sub-biomes adding them will require a new map, like the temperature and humidity maps, the new map will have numbers going from 0 to 100, so depending what range the sub-biomes will have, it will affect which sub or parent biome will be selected.

I mentioned in the previous post that I optimized the generation of the heightmap, thanks to that optimization and the lake algorithm I was able to sped up the isometric image rendering which I can now use in the cube creator to view different landscapes faster.

I also finally added the 3D model of the character to the game as well as tree felling.

Me and Samuli been talking and designing quests for the game, nothing big just some examples, we want to have dynamic quests that are build from multiple different quest pieces, we've also been trying to make the quests so that there are multiple ways to complete an objective, the player can decide how he would complete said objective, we would only give a possible direction from which the player could complete the objective.

Seemingly impossible lake part 2

I ran to a problem with the lake algorithm, as I create it by using a heightmap and the problem with this was that holes in the ground will not be filled, of course I though that just creating a floor under the lake and walls at the border will fix this but there was one special case to which this "fix" did not work very well, here's a picture

As you can see there is a huge hole here and the reason for this is that above there is a cliff which makes it the highest elevation in the heightmap which in turn makes this side of the mountain not being filled, thankfully fixing this was quite simple and effective but it does not follow the wall perfectly as it will convert some blocks to water making the wall a little more linear.

Other than this problem, I've optimized the lake generation as well as the creation of heightmap.

Oh and I did try to do something about the rendering of chunks as the useless garbage allocation is insane, but the mesh creation in unity blows and I can't actually prevent useless garbage allocations, but I did make it a little faster and use less memory

Seemingly impossible lake

I've finished adding water to the game sort of, I can generate lakes and render them but there are no "fluid simulation" happening, yet, and there are still a lot of things that I have to think through before I can officially say it's finished.

So how did I add water to the game, it was actually quite difficult as the terrain is easy to shape but adding something like liquid is harder as it can spill, overflow and so on, so what I first did was
I created a heightmap from the coarse noise map from which I searched spots where a single water could be placed without spilling, after I had done that I made a sort of a filling algorithm that would raise water to nearby neighbors until a x number of nodes were found, then I remove all nodes that have neighbors (except ones that have been found) that are lower in height than the highest node that was found, now I had possible lakes that could be formed but there was another step I had to do.

Left has water locations, middle one lakes and right is the heightmap.

Next up I created a heightmap from the finer noise map, now that I had all the lakes from previously, I go through all of the lakes and find the lowest point of each lake and I locate them in the finer noise map from which again use a filling algorithm, this algorithm is essentially a better version that I used to find the lakes. The result does not fully represent the lake that was found from the coarse map as the finer noise is modified slightly to add slight differences to the terrain.

I can't create all the lakes in one go as it takes quite a bit of resources and space from the harddrive but thanks to the coarse map I have all the potential lakes from which I can actually generate them from.

Below is a gif of a lake, not the same one as in the heightmap.

View post on imgur.com

S-...Sleep

Well I've finished creating the template for Foraging, there is a chance to gain items from foraging and you can level it up as you are doing it, leveling foraging for now gives you a better chance to get items, later I might add different foraging types such as finding weapons/armors or other valuables beside food and resources.

I've also been programming the inventory and character GUI which has taken most of my time, currently the inventory slot functionality is mostly done, some item splitting and such features are missing as well as using items, the equipment side is not done. In the character side I've finished the needs, health and mana but still working on the skills interface.

Programming the character saving is becoming quite the tedious task, I have to split a characters information to several files, if a character is not important it's useless to save such as inventory or skills because they can be generated by a seed. Splitting the inventory and skills to different files also helps me in adding more skills and other data as I've yet to design and define them because all of the characters data is converted to bytes so I have to carefully "map" each variable in the save file.

PS: Oh and I've been cleaning for 3 days straight with little sleep while friends are playing DnD? thanks.

Slow progress

I've been sick for a week then struck a heatwave, I hate high temperatures and working without any kind of air conditioning is horrible, so I've only been working on memory usage and trying to eradicate all garbage, other than that it's been quite quiet.

Oh I have been searching for more ways to improve the terrain generation and looking for ways to add water and there has been some success although I've yet to implement any (except for one image below of random generated canyons) but it's looking promising.

Gameplay and more terrain generation

So I've more or less finished the refactoring and I've begun adding some gameplay elements starting with foraging items from the ground and proceeding from there to some basic survival mechanics, crafting and building, after that I'm adding some neutral and hostile npcs with which the player can interact with. I'm also trying out some different terrain types to see which I should use and so on.

Samuli also has modeled some house parts for the game and I'll be adding them once I have programmed building.

PS: I'm still updating the task list at Onwards

Latent optimizations

So I've been refactoring the project and changing most of the integers to long so I can generate larger maps is going well, there were some hiccups here and there but it's still an ongoing process.

I also noticed some potential optimizations in the chunk rendering part which I've now added, I noticed these because I changed the cube array in the chunk to the length of 4096 from 2048 to take advantage of the previous optimizations (which I mentioned here Rivers, streams and more optimizations), the change was a double edge sword as the chunk rendering took twice the amount of time to render a chunk, fortunately I noticed that there were some potential optimizations as it sped up the rendering from 5 to 11 times faster.

I've also reduced memory usage by hundreds of megabytes depending on how many chunks are possibly visible, I only removed index an int variable and a vector3 position from the cube class as they can be easily generated if needed, as I mentioned a chunk has 4096 cubes and over 8000 chunks can be visible, the amount of memory needed for position and index is massive.

One down, thousands to go

So I finished creating the GUI based on Samuli's concept art and I can now start working on the gameplay... not.

I found a memory leak in the terrain generation that's resulting either in garbage collector not clearing or it's something I've done, I'm guessing both, so I have to trace it which means refactoring the terrain generation, although this prevents me from continuing the gameplay, but good news is that I can modify the terrain so I can create the actual size I was planning.

I was also planning in adding the cube unwrap which I've talked for so long now, but it dawned on me that the normals in the mesh would suffer, rendering a cube properly would need all 20 verticies otherwise I would need to rotate the angle of the normals and I have no idea what that would look like...

Rendering problems

So I had noticed in the beginning that there were problems with the GUI rendering transparent textures, the textures were missing either pixels or were rendered in the wrong order.

I used a transparent cutout shader to display the textures "properly", but there were problems of course, specifically because I used alpha testing to render the opaque pixels from the texture while writing to the depth buffer. In the next pass of the shader I turned depth buffering off and prevented any pixels from the depth buffer from being written again, after that I had turned alpha blending on and it wrote the transparent pixels. It all seemed fine and dandy but it did cut some of the more transparent pixels off.

I removed the first pass and now I only have the second pass in the shader (the shader is close to an unlit transparent but with vertex coloring) and it seems to render fine, expect for the sorting of the triangles in the mesh, which I had to add in to my mesh rendering. The only problem with it was with the rendering order with other gameobjects, they were either always shown on top of the GUI or the GUI renderers din't show over the others renderers even if they were closer to the camera. 

This was really weird and I looked everywhere for this problem, I though that the problem was in the mesh as the unity's cube mesh would render correctly with the same shader and this puzzled the hell out of me. Finally I found the answer and it was in the material, more precisely in the renderQueue member of the material. The renderQueue was set to 1 every time a texture is changed by script in the material (maybe by modifying other members in the material as well), the number in the renderQueue is the same tag as the shader's Queue tag which are:

1. Background, 1000
2. Geometry, 2000
3. AlphaTest, 2450
4. Transparent, 3000
5. Overlay, 4000

The renderQueue tag is set automatically if the material is modified by unity, but if it is modified by script it will set it to 1 which is nothing and it would result in a very chaotic rendering order, by setting the renderQueue to 3000 would result in a correct rendering order with other gameobjects.

Moving on

I finally finished the new GUI framework which took ages to complete, but now I can finally have an easier and less frustrating time creating the GUI for this project. I've also tried to make the framework as user-friendly as possible while being flexible and able to do complex GUI's.

I've also began creating the GUI for the game using the textures and concept art I received from Samuli, when it's done I can continue working on the gameplay for the game, specially the character's skills.

I'm also eager to change the chunk size to 16 * 16 * 16 from 16 * 16 * 8 as well as adding the cube unwrapping so I can reduce the vertex count.

Upgrading

I recently upgraded from unity 4 to 5.4 and to my surprise the game is running more smoothly specially around trees.

Why I only now upgraded to unity 5 was because I did not believe it would boost the game in anyway specially in how unity handles custom mesh data (I wish unity would take arrays as references or at least give an option so that I can give it an array with an integer to let it know of how much of the array I'm using so I don't have resize the array every time...).

I also began to reprogram the GUI for the game, because it was lacking in features and it was quite a pain to work with, why I don't use an existing GUI is because I know what I want from it and I can optimize it for that purpose and to make it work the way I want it to. You might think it's reinventing the wheel and you would be right but if people don't at least study or try to create something that has already been done they don't advance as a programmer, besides I've already done this once and I can create modding support and modding tools for it at the same time.

I've also been thinking if I should sell the GUI in the Asset Store, but I'm not sure if anybody will buy it and if it's worth all the hassle to get it into the Asset Store. I also been thinking if I should join Patreon and if I do then I'll just share it for free there...

More on the GUI, it will be fast, responsive, automatic scaling and relocation based on resolution, it will have buttons (with a delegate, mouse over, down and normal textures and a tooltip), uniform and sliced scaling, text (which is rendered from a bitmap), able to use a texture and render it in a circle with a varying central angle and to create a drop down menu with menu items hidden outside the menu even when scrolling, the GUI will be stored in an XML file and if the GUI was not saved it will be also serialized to the scene or prefab so no changes will be lost, also because it can be saved into an XML file changing the GUI while the game is running is possible and it's possible for the user to change the GUI, this of course can also be disabled, the GUI can be modified either via the scene or script.