the cart before the horse

Since the result of my workarounds has been quiet productive and I'm so happy with it that I want to show the minimum detail, I'll leave the what are you working on thread in peace

This project is not purely a game project, but a game visuals workaround. It borns surfing in the cartoony fashion because I love super deformed characters. So the first thing I did was drawing one. I finally chose a knight enclosing the visuals into a fantasy theme, but it could be any other.



I always thought in a top down camera because it is far easier to manage. You can forget about mipmaps, lod stages and splits on sun shadows. Texture resolutions are easier to adjust too.

The main idea is mixing highly contrasted hand painted textures with an oldy goraud lighting and highlight the volumes with SSAO and PSSM shadows.





I wanted to contribute to the super deformed taste with a big camera arc and some tall playground limiters:

continue...

and detail maps for the terrain:

Simply wow...awesome, iam fan of this project. I like the model and the graphic style.

Would be cool to mix this game with great heavy enemys and cartoon blood like seen in metal slug.

Do u make all the models yourself ? The rocks too ? If u sell models someday, please let me know ^^

where can i buy it ?

ups sorry, I forgot to mention that all those static models are downloaded placeholders with texture color switches and backed lightmaps by my own, except the grass and the tent that are fully mine, the worst models indeed

Awesome, you've inspired me to seriously consider this style for my current project.
Love your Tube clips....

Thanks

It is the moment to know if I am able to draw assets in one single style. The first try goes to a seamless stone wall texture. Not really fine but it is an aceptable approach.

Looks awesome!

May I ask how you calculate the ambient occlusion?
I'm currently using a randomly rotated kernel (normal oriented hemisphere) with 14 samples and a 5 tap filter but the result is still a bit noisy and not that fast...

this ao fake is not a spatial calculation but a screen calculation. Since the polygons depth is in a small range it looks good. The depthmap is in view space.



I blur the result with a 5x5 cubic gaussian blur in two stages

thanks for the information!

I got some ideas around particles and bones

First steps on enemies behavior. The dynamic obstacle avoidance is a 2d geometric computation with no c_... involved.

can you tell me a bit more info about it? do you use something like potential fields?

Just as a tipp, you can actually embed YT videos here. All you need to do is to switch to "using HTML (and UBBCode)". You get the html-stuff from under the YT video (Share->Embedding).

@Hummel,
html code? it sounds pretty dangerous
I have to be blind because I can't find the switch to "using HTML (and UBBCode)" option anywhere. I reviewed my account preferences, I tryed to edit the topic because i read that UBB forum html option is in each topic. I'm lost. The youtube tag does not work.

@sivan
I will try to explain it. I devised it from scratch with the premise that all the enemies look for the player. In other cases it will not work because the whole algoritm remains in this premise.

I allocate all the enemies in an array that I sort each frame by distance to the player from nearest to farthest.

The next thing I do is create some obtruction lines with the near neighbors in the array when the distance between them is not big enough to permit the access and I allocate the lines in the narest of both enemies involved in the description of the obstruction line.

That is all the data I used to compute the avoidance. I move the enemies in the array order. First I set the player as actual enemys' objetive. I check if the ray between the actual enemy and its objetive is cut by any of the lines allocated in the previous members in the array, from previous to the first. In the case a line intersects I set the actual enemys' nearest line contructor enemy as the objetive for the actual enemy and I save the turn sign to enforce further intersection turns to same side.

Next I check the distance from the same ray above to the previous members in the array, from first (or the previosly set objetive) to the previous of the actual enemy. If the distance from the ray to the enemy is lower than the summatory of both enemies bounding radius, I set it as the actual enemys' objetive.

The last action is to turn the vector from actual enemy to its objetive in order to to get out of the bounds of the actual enemies objetive in the case that an intersetion has been detected.

It works pretty good and fast for my needs.

Hummel is right, but he forgot that the HTML-switch is only available for moderators



Looks good, but I notice "jumps" in the position and angle of the enemies; there is something wrong with that and I guess you already know For a prototype I had also a plane with lots of enemies (10-100) targetting one single player entity. I did it even simpler, the boundary condition was that the area is more or less obstacle free:

• calculate distance to player and check if we want to follow him
• if yes, calculate the angle to him and turn to him
• run into that direction by using vec_add and the direct vector from me to the player
• after moving, check the player and all other enemies if I am in the boundary radius of them; if yes, push away with vec_add from them

This simple approach worked fine for me, you watch it here (Razor for my Valentine Trailer).

thanks for the detailed answer, quite interesdting, seems to be a unique solution, but sound a bit complicated, but if works fast, it's okay but how do you ensure avoidance of other level geometries?

I read yesterday a robotics based simple method what I want to try out, where a grid or node based database is needed, static obstacles and dynamic agents have a repulsive and the target an attractive field effect, they can be summed and weighted, and each agent examines 4 neighbouring grids in the cardinal direction, and sets a moving force, this way a natural acceleration, deceleration, and obstacle avoidance can be achieved, and agent turning also can be handled easily. to avoid stucking in balanced areas a base force can be applied to each agents. just an idea I thought to share, and maybe I was not totally exact.

thanks for the fresh ideas

I first tryed something similar to HeelX approach but did not find a convincing behavior. While thinking for a solution for playground limits I thought on this line system that lets me use segments as playground limiters and compute the whole enemy collisions same way. The static obstacles are supposed to be points+radius into the enemies array but without moving code. Since all the obstacles will be sorted in the array, the player collisions are very easy to compute too