New demo which shows off the new post-processing effects. As you can see, we now got both the graphics quality we need, without sacrificing the frame rate we deserve!
The minimap now shows icons of important locations, and thereâs a new compass that tells you in which direction you need to go to arrive at your quest destination.
Getting the minimap extensions to work was, once more, a real pain, as somehow I again managed to find bugs no one else had yet found. The main issue was the map frame of our UI not scaling correctly around the minimap itself. The developer of the minimap/compass system was very helpful though, and after testing two new beta versions we finally got this to work reliably.
1 Like
This is proof that the basic game mechanics are now working: we got ourselves our very first quest! Itâs a simple mission, but a very important one nonetheless. What do you think? What is good already? What can be done better? And the most important question: can you find out why the main character suddenly feels stronger? Look carefully!
To get this working, several core mechanics were implemented, some of the basic story architecture was modified and several assets had to be programmed (like the opening door of the cage). And of course everything has to work together: the door can only open after the key has been found, if you click on the lock while the key has not been found yet, the door may not open, and all those other scenarios that are very easy to forget if youâre not careful. Testing, testing and testing is the only way to find all possible scenarios.
We also got ourselves the very first basics of something that can be called an inventory. Currently itâs only one line of code remembering whether we got ourselves that key yes or no. But the rest of the code is communicating with this inventory, which means that it can now easily be expanded. The next step will of course be to actually display this key in an inventory window. Then comes inventory management, et cetera, et cetera.
1 Like
You know what they say: it takes 10% of the time to make the first 90%, and 90% of the time to make the last 10%.
Today we bumped into an enormous issue with asset management that had to be solved due to a huge bug in Unity. We did manage, and under the hood lots of things changed, but itâs not something that is visible on your screen. What the new management does do though is make sure that weâll be able to extend on what we have.
We also polished a few details in the first quest, solved some collider issues in the woods and implemented a new tutorial system explaining important things to the player. Here you see it in action.
We got ourselves a new log window, that currently displays tutorial instructions in case the player forgets. Later the window can have more purposes. Next: a quest log window!
In hindsight this was pretty easy to accomplish, had I known earlier that Unityâs ScrollRect is outdated and that the new ScrollView is the way to go. But alas, we all learn, donât we?
We got ourselves a brand-new quest log, for keeping tabs on all the juicy missions you will get. Enjoy! Integrating this part with our UI skin was a pain: not because itâs difficult, but because you have to be painstakingly precise to fit everything together.
Most criticism from followers was about the fact that the main characterâs animations were off: he was moving nervously, his staff was going up and down all the time while walking, he didnât carry his staff on his back, and he wasnât running but speedwalking. It took a long time to tweak this and get everything right: the character now runs more naturally, and he carries his staff on his back only to put it in his hands when he actually spots an enemy.
Oh, and did I mention we found a huge bug in the player movement script, that was doing all kind of things with the running speed? And we only found out after several weeks!
Today I had my game playtested a bit by Noah and Aska, my two sons who are both avid gamers. I got lots of feedback on the combat, which has all been implemented. The player now sees himself as an icon on the minimap, a bug with AoE spells was solved (you could basically trigger the spell and spend mana for that, without actually hitting the enemy), enemies now attack the player if the player hits them from outside their attack radius (so you can no longer just shoot at them from afar), the water was made more foggy and the Quest HUD on the left of the screen now links to the actual Quest Log window. Also a static inventory window was implemented; now I need to get this thing moving.
Weâve got ourselves a first version of the inventory. It keeps tabs of all items you find and displays these in the inventory slots. The inventory window itself can fade in and out. Now visually this may not look very impressive, but thereâs quite some code behind all this: it doesnât only work for one item, but for all items you will ever find in the game.
1 Like
Selectable enemies
When youâre outside melee radius and left-click, you obviously canât hit the enemy with a melee attack. What you can do though is select him for a magic attack. Until now magic attacks were sent either to the clicked enemy or the closest enemy (when triggered from keyboard), but now you can also specifically set a target, not necessarily the closest enemy, for magic attacks from your keyboard.
Highlighting enemies is not as easy as it sounds: you need to calculate its outline first. This has all been done before and it would be a waste of time to re-invent the wheel. Therefore, we used a special asset called the Highlighting system, which works perfectly in this kind of situation.
The newest game trailer with updated UI and animations. Spread the word!
Close-up shots
Today I made something pretty complicated, to grab the attention of the player when itâs needed. The music changes and the camera moves from the player position to an important object the player needs to investigate. The camera stays there for a few seconds, and then moves back to the player again. After that, the normal background music returns.
To make sure the object stays in focus, depth of field needs to be turned off temporarily (the aperture needs to be set to max) when the camera is near the object. For this Unityâs badly documented post-processing volume needs to be addressed. Also, player control must be cancelled when the camera is traveling, else the player will be able to move the traveling camera, so that it will never arrive at its original position anymore. Not only that, the player would be able to move the camera away from the object in question too, so that he would never notice it. These issues have all been addressed.
What made this most difficult was the fact that the behaviour of some of the objects involved in Unity (Post Processing Stack, Audio Mixer) differs from their behaviour outside Unity, making it very hard to debug the code. Another very annoying bug was the fact that the player could slide from the landscape during the cutscene, so that he would trigger the end of said cutscene halfway by leaving the cutscene zone involuntarily. I solved this by expanding the zone while playing the cutscene (not very elegant, but it does the job).
I think this is a very cool feature that weâll use pretty often in the game.
The last few days I spent implementing a new environment: the church. Collecting the right assets (both graphics and music) and setting the right tone was quite a task, but here we are. Iâve also started the implementation of UMA, a very powerful but also very complicated system that will enable me to implement hundreds of different bodies, faces and clothes into the game. Once my wife remarked that of the three NPCâs in the game, all of them had the same face, I knew I was in for trouble. I havenât got UMA working for the player himself yet, but if needed we can just keep letting him use the standard model as is: itâs unique in itself.
The priest in the church is the first model using UMA, and though you wonât notice much difference with the other models in the game, itâs important to realize that this is not a static model, but one that can be changed into hundreds of other variations: id est, itâs a proof of concept that this is going to work, and that it will be possible to get hundreds of NPCâs in the game if needed.
Unity is heavy software, and during the upgrade to 2018.3 I had to wait several hours. A great time to start writing a story in good old Notepad+ A good story, I think, doesnât paint the world black and white, but involves hard choices that are neither good or bad.
Now, Iâm not going to pretend this is becoming a non-linear game. The game development is a one-man show and there are simply no resources for that. So yes, the game will be as linear as hell. Still I hope that the player will be able to relate the heart-wretching choices the main character has to make, and hopefully youâll have some difficulties shaking all this off when you try to go to sleep.
2 Likes
Development has been absolute hell the past few days. It became clear that we had to rebuild a large part of the game to be able to accommodate to multiple characters, with different faces and clothes, not to mention the fact that many of these characters will switch clothes and weapons during the game. Fixed character models were no longer enough, and everything had to be adapted to the so-called UMA model, a flexible character model that enables you to mold bodies and equipment in any shape you wish. One nasty bug kept us busy for three entire days (the character got stuck in the landscape and was unable to move), but thanks to the help of the great people behind UMA, we finally found the culprit (it was the AI Character Control that navigates the character through the landscape if you click on the landscape instead of using your WASD keys).
The result? Exactly the same game as before, but with a lot more flexibility for the future: we can now accommodate literally hundreds of different characters with different haircuts, faces, ears, noses, eyes, shirts, pants, shoes⌠you name it. For an RPG, this is an important feature.
Meanwhile Eppo has been working on one of the main music themes of the game. Lots of music you hear in the videos is still stock music, but the plan is to replace all of this with our own music. In this video you see some of the progress we made. The music is by far not final yet (what is, in a game that is still in development?), but it should give you an impression of what weâre aiming for.
The beautiful thing about UMA is that it enables us to come up with a basic species for an enemy, and then variate on that slightly, to avoid all enemies from that species looking the same. Bandits for example have a greyish outfit and wield a club, but they have different faces, haircuts and hair colors. Here you see the new UMA system for enemies in action.
2 Likes
Under the hood, many things are happening too. Today we established a link between our Inventory (C+) and Dialogue System (LUA), so that we can display certain dialogues only when you have a certain item with you.
NPC behavior
Welcome in Dyllanâs bandit camp. NPCâs shouldnât just stand and idle in the game. To make things more realistic, they should do stuff: watch the horizon, pick something up, scratch their heads, wander around. But programming this for every single NPC in the game is a huge task, so itâs better to automate this. Thatâs exactly what weâve done: all looks and animations you see here are completely randomized. We throw dice between certain margins, and these decide basically everything, varying from the length of his nose and his walking direction to the activity he undertakes and the cut of his hair.
This is harder than it sounds. We donât want NPCâs to walk through objects, so before they start walking to their random destination, we first cast a ray in their forward direction with a length of the distance between the NPC and the destination. If it hits something, we decide not to walk and go for a random animation after all.
The foundations of this system, letâs call it NPC AI, have been laid and can now be easily expanded upon.
1 Like
Well done! 
1 Like
We can swim!
Ladies and gentlemen, we can swim! These are five different animations combined in a blend tree, linked to programming logic that detects when the player is under water.
We have also implemented some optimalizations, as the game was suffering from 15 FPS lag spikes on Ultra settings. These have now been reduced to 50 FPS lag spikes by programmatically shortening the camera culling distance of small objects like grass and flowers: we donât need to render flowers that are 500 metres away if they are barely visible with the naked eye from that distance anyway. The standard culling distance settings in Unity were too crude, but programmatically itâs possible to set the culling distance per layer, which gives us exactly the control we need.
3 Likes