Amazing work!!!
1 Like
Version 0.104
Wolf pet implemented that can walk over terrain and has three basic animations (run, stand and dig). It follows the player and heals us when we stand still. I’m slowly starting to understand how the Animator works, so a lot can still be refined in the future.
The player is now also animated when he hits the enemy, and each hit produces a sound.
Version 0.107
Wolf and attack range refinement. Reinstall of EnviroFX and AQUA because of compiler bugs. Everything is clean now and no errors are produced.
Wolf now flees during fights and says Kaikaikai! when he does so. He’s not a hero and hates fighting. Maybe this will change at higher levels. But once the fight is over, he will come to you and heal you, like the loyal pet he is.
New archer model implemented with arrow nocking animations and archer enemy behavior. TODO: Implement enemy melee animations.
Version 0.109
CTS (Complete Terrain Shader) activated.
All three enemy types now have 2 die, 6 weapon swing and 1 fist blow animation and sound. Die sound based on gender. Enemy behavior completely reworked to accommodate for both ranged and melee types. TODO: Types that can do both melee and ranged.
All enemies have varied animations. Enemies and BGM have a completely revamped combatStatus system.
Enemies now share same audio bank and are working correctly. Audio mixer implemented. Note for self: if you implement an audio bank that you instantiate under each enemy’s hierarchy, don’t forget to reset the transform to Vector3.zero, as else the enemy’s vocal chords will hang somewhere in a tree, so that his voice becomes completely inaudible with 3D sound. Only took me five hours to figure out.
Version 0.115
New enemy type with heavy-hitting fire arrows (this is for Ben’s trail assignment).
Version 0.134
So this all started when Ben proposed to put colliders around weapons to make them hit more reliably.
I worked two whole days on it, fine-tuning and everything, but in the end the result was just not what I wanted. The whole combat felt sluggish, and when I started to implement box colliders for enemy weapons too, it got even worse. A big problem was the fact that weapons have different lengths, and that with this system, a player with long weapons would always beat an enemy with short weapons: the enemy simply couldn’t hit the player.
I then tried to solve that by giving the player and enemy more control about the animation they started, but before I knew it, I was trying to develop a physics combat simulator instead of a role-playing game (the player alone has 12 random attack animations: for full control you’d need 12 buttons or combinations of buttons just for that).
As in computer games you simply don’t have the control you have in real-life (to be honest, even the fantastic combat in games like The Witcher feels sluggish), I decided to get rid of the whole idea and simply count something as a hit when the enemy or player is close enough. This plays a lot better… if I cared about realism I wouldn’t spend my evenings hitting orcs on their heads. In the end gameplay is what counts most, and now I have slightly realistic combat which great gameplay: the character always does what I want him to do, he responds speedily and I feel in total control. I want to play an RPG, not an arena game.
I also implemented Scriptable Objects for enemy weapons, but that simply doesn’t work, as the transform a weapon needs is different for every enemy, whereas the player always uses the same transforms. So I gave up on that idea and will build each enemy type from scratch.
As you can read, I did lots of coding, but it was a frustrating process and in the end I had to delete everything and go back to a previous build. It really hurt, but sometimes a man’s gotta do what a man’s gotta do.
Good news too. I finally managed to enable enemies to switch between melee and ranged weapons, including sounds and animations. This was incredibly complicated, as there are so many possibilities. Obviously enemies can’t use the idle switch animation while running (chasing or returning to base), so if they are running, they have to stop running first… et cetera. I think they now have dozens of possible enemy states, but I believe this is as complicated as it gets. The beautiful thing is that I can now give enemies melee weapons, ranged weapons, both or nothing, and they will act depending on which weapon(s) they have: an enemy who has both types of weapons will switch, an enemy who only has ranged weapons will not switch to melee, an enemy who only has melee weapons will not switch to ranged and an enemy who has nothing will simply start fighting with his fists.
All enemies share the same sounds, and I’m currently instantiating a special game object containing only audio sources for this, setting its transform to the enemy. After Ben’s latest video I learnt that Scriptable Objects can probably do the same with less overload, so that’s probably something I’m going to implement next.
I also bought myself GAIA’s Path Painter which makes it easy to paint paths (and in hindsight: to flatten the terrain for buildings, which are a pain to put and connect correctly to the terrain and the terrain’s nav mesh). Look at that nice path through the village and the new cosy tavern!
Last but not least: lots of changes under the good to make the architecture more robust. The problem is you don’t see anything of this, but it does enable me to expand the game more easily later.
Here is the result! I’m proud of it. See you in the next update!
P.S. The combat status is changing too often. You can notice this for example by the music that is constantly changing. This already has been solved in the next version.
2 Likes
Version 0.148
I’ve been experimenting with my audio equipment to get a hopefully nice and warm voice. Implemented opening story with fly-through camera. Also started new Story namespace, which switches between cameras/audio listeners and controls story flow.
1 Like
Version 0.164
We’ve got new special (currently magical) attacks with new mechanics, sounds and animations! The first one (working name: Gore) is a direct attack used for stronger enemies. The second one (working name: Waterfall) is an Area of Effect attack used for bigger groups of enemies. The values are still very arbitrary: this is just to give you an idea!
2 Likes
Gore and AoE animation effects, sounds and positions refined. Sound now uses round robin (one of the five random voice effects is chosen during cast).
3 Likes
Version 0.180
Mana regeneration, player has die sound and animation, scene reloads after death, enemy has random attack speed variation, improved health and mana bar with visible bubbles, complete UI overhaul, selected abilities now temporarily glow after selection.
2 Likes
The main music theme of our upcoming RPG Another World, accompanied by early-stage slides giving a small impression of the game.
1 Like
Full integration of new nature graphics, new post-processing and new vegetation studio. These are in-game graphics, at 80 FPS!
1 Like
A new and shorter trailer of our game, which hopefully has much more impact and better lighted scenes.
#rpg #indiedev #gamedev #anotherworld
1 Like
And we’ve got volumetric fog! Introducing The House in the Woods… This all was inspired by Rick’s lecture on fairy dust. I was like… let’s take this to the next level.
It took some time to get this working for one of the more dangerous zones in the first zone, but we’re slowly getting there. The fog gives this place an eerie atmosphere, and I wonder if anyone dares check out who lives in that house…
We have also optimized the game, which now shows much higher framerates (up to 80 FPS should be possible on low-end systems, and even that doesn’t look too bad!) and solved some issues with colliders in the woods (the player was constantly stumbling over mushrooms and moss – not very heroic that, right?
One more screenie, to show how this looks in daylight.
Like it or not, in RPG’s you need to talk. A lot. For that we needed a robust dialogue system, which has been implemented today. There is still incredibly much we need to tweak and configure, but at least we made a small start.
We also implemented dozens of character portraits for the many NPC’s you will encounter during the campaign of Another World. But we’ll tell more about that… in Another Posting.
After solving multiple serious conflicts between several modules in our game, we finally managed to get the dialogue system stable. It can now scroll, use different colors and show NPC portraits. Also, the camera zooms in to the NPC now when you strike up a new conversation.
1 Like
Today was an absolute nightmare. I spent 15 hours at a stretch to optimize the game, implement new magical effects and solve two bugs with the caustics in the water. For this I spoke with three developers of modules implemented in the game, who all gave fantastic service, but had to admit themselves that somehow, I had succeeded in finding bugs no one else had found yet. Why is it always me?
The newly implemented magical effects look oh so beautiful and much more sophisticated than the older ones, but due to a bug in the rendering of decals in Unity, they caused lag spikes up to 1 FPS. Mind you, that’s on an i9 with a 1080 Ti and 64 MB of RAM on board. In the end the Vietnamese developer of the effects and I decided to temporarily turn the decals off. Then it turned out that the spell effects assumed they were always alone, so that subsequent hits of second, third and fourth fireballs fired in succession were never detected. This I had to solve myself.
Next were the caustics in the water. I spent two hours with the German developer of the water module to find out that both bugs were caused by the new vegetation asset I had implemented in the game. This was eventually solved by moving all vegetation to different layers in the game, and then have the water engine ignore these layers when projecting the caustics.
During all this I also communicated with the American developer of the vegetation, who was already aware of said issue, so though tiring, it was a very international happening
Anyway, here is the result. I hope you like it!
3 Likes
I have connected the dialogue system to the game world, so that we can trigger effects in said game world based on choices made during the conversation.
I never liked the idea of characters standing up when leaving a conversation (the player could follow him around, trying to strike up conversations, and no matter what, the result would feel unnatural anyway), so instead I chose to simply fade the characters out. For technical reasons, this is harder than you think, due to the fact that a character consists of many materials and meshes, each with their own properties, each fading out in different ways.
2 Likes