Journey into sight and sound

[Alienhead]

Since the game jams I want to to enter are still months away I figured I'd take some of the stuff I did for the Weekend at kekes project, mix it somewhat with the AVbot project  and see what happens.   This project features the environmental controls i made for Keke's, the foliage system I made for ftype, the battle controller from avbot and the towerdefense plugins I wrote for defendThis!.  My idea at the time was to make all these parts and pieces interchangable so I could drop the systems into any project and they should 'just' work.  Well that's precisely what I've done here and for the most part, it's coming together.  At least everything is communicating together, so I have a basic skeleton of a game - now to actually build something 'fun' around these systems and call it a game title.

This time around the bots are using actual pathfinding. 

This is only a test, nothing playable here yet.  If everything turns out the way I hope it to, I should have a playable open-world towerdefense game based off the fast paced gameplay of avbot..   we shall see ! :()

  

Credit to havenphillip for his awesome work on the dof.

 

[Alienhead]

Okay, I think I got the color platelet worked out, the screens from yesterday were to bright and the second one two dark.  A fine balance between pastels, specular and bloom outlines make all the difference.

  

[Josh]

I think this is basically the idea behind the component approach. I don't think components are ideal for programming, but once you understand that the user who is asking for these usually does not know how to program, and does not want to learn, then it starts to make sense. I think this is why a lot of indie games seem like they are able to support fairly advanced functionality, but then the author can't fix very simple issues. This is probably not ideal, but it is better than the alternative not being able to make anything at all.

[Josh]

With Vulkan code, I can't just jump right into it and know what is going on. It takes me a while to poke through the code and figure out what it does, even though I wrote it. I have to do this every single time I go back in and change something. It's just too complicated to keep it all in my mind at once. I think this is probably how most people feel once code gets beyond a single component's contents.

[Alienhead]

You are so right, an understanding on how the mechanics work is a major part of coding, not just memorizing some command names.  

[Alienhead]

Thought I'd share this technique I've used for sometime..   In my project I have a full 24-hour environment cycle. One easy way to achieve the shadowing is to attach 2 directional lights to an axis rod and slowly rotate the rod, turning on and off the appropriate light according the hour.

To further the effect I have setup a tweening routine that handles ClearScreenColor,  Main light color, main light specular and ambient color.  I then used a RGB chart featuring a dusk to dawn platelet to setup each hour's coloring.  Seamless tweening between hour changes is handled by a simple Lerp call. So going from 6am to 7am coloring platelet is seamless. 

The shadows are handled automatically pretty much. The directional lights attached to the axis rod do all the work. A slow rotation of the axis and the shadows stretch out in a real to life way. 

I had to modify a few of the drawing shaders, added a uniform Hue  to them so I could self-color the tree leaves and grass with more detail than normal ambient or directional lighting provided.

To further the experience I have the tween system setup to use real time, so the system OS time actually matches that of real life. But there is also a game mode setting that can be turned on that puts 15 mins of real time down to 1 min. 

You could also throw in fog and 2 different skyboxes and tween them into the scenario as well but in my case I'm using a heavy DOF effect which pretty much blends my horizon line automatically and using a skybox in this setup is irrelevant since it wouldn't show up anyways.

I still need to do some grass work, I'm not really happening with it's look, I'm designing some softer more wavier grass which I'll have in next week.

All in all I'm pleased with this aspect of the project. Time to move on to Ui system.

  

[Alienhead]

This system works as expected, just one hitch - the transition between 5pm and 6pm is the change over hour, I have to turn off one light and on another and theres really no way to transition that. So out of the 24 hours, I have 1 second of jerky change over. I can live with that.

It's got a really good stylized look to it without having to use a toon shader. ( phew ) .  This is being ran and recorded off my older testing hardware as well. 

 

 

[Alienhead]

A much different stylized look, I turned off bloom, dof and saturation  in the config, reworked the toon outline shader some to give a more  smooth, single outline to 90 degrees in front of camera.  

I've made all these shaders togglable in the gfx options menu.

Also completed water with hue shader settings and several of the gui templates i got finished. 

    

[Alienhead]

I got npc's in the game now, they really only hand out the quests but I gave them some ai for wandering, and doing little side jobs. You'll have to keep them out of trouble with the goblins if they wander off 'too far'. Also cleaned up some of my game logic code and gained about 20% increase in fps.

 

[Alienhead]

What do you suppose is happening here?  Some of the most fun things to do in a 3d game is play with physics and break stuff..   So I thought what the heck, why not have my wizard fire crystal/glass orbs instead of fireballs...    Just as I figured, I've spent the entire morning playing around with this instead of furthering the project, and I haven't even got the breakage part yet.  lol.