Haha cool and that reminds me of a similar Kingdom Hearts minigame I played a lot
https://www.youtube.com/watch?v=Vf9QlI5fBLY&list=PL_9mC7wi4OiInaHGs9SiVAFOqjlrTp9zc
2 Likes
Yes looks nice, there really a lot of games i played in this style. But this Kingdom Hearts reminds me more like Sega Saturn Longplay Panzer Dragoon - YouTube, or Star Fox 64 - Complete 100% Walkthrough - All Routes, All Medals (Longplay) - YouTube.
I tested this also but just decidet the first will be something with zombies, just i love gore 
And here is the mostly final result of how i will use the combined HitZones. Just the most simple way that works perfect while i tested would be to select the hitted collider based on the bone (and you can stick with the build colliders in PhAT). Then switch with a int Enum set a int nr for “iHitZone_x” and run the code afterwards.
I use an int for this because this way i is easier to expand based on this (Just like this more than an Array in this case).
@TechLord i put a little overview in here that might help you to get a starting point for dismembering.
3 Likes
46:00 Now I know where the hoverboat vs alien combat inspiration came from in Beyond Good n Evil ;') good stuff.
If it works now that’s alright keep it :). Technically if you want the “key” to be both descriptive and easily expandable you’d be quickly thinking of a map of bone name to hitzone(s). in c++ you can get creative with oneliners to pull data from a container without the need for a switch but I believe blueprints also accepts FName to be used as a switch argument. Thing I just wanted to add is that I prototyped in blueprint with enum in the past and blueprints has a habit of corrupting enum nodes when you move around a value, add or remove one. They just turn to “byte” or force you to recreate the nodes which is especially annoying with the more complex nodes in animation blueprints.
*Edit forget about what I said if you are not using blueprints at all lol
1 Like
No i only use them for testing out things faster. BP´s are very good for small things but if you have more complex calculations it just is much slower then using c++. I tried to mix this but this gave me more headache then it is worth .
I learnd to keep things as simple as possible as i started with coding many, many years ago. The more complex it gets the more sources of errors can apear.
I am very glad i can discus and talk about this, you get new ideas, help or it just makes you rethink a few things. Never thought doing this alone would be so hard and takes as much time as it does.
I am very thankful to everybody for all the suggestions and feedback i recive. One of the best ideas i hade during development was putting my project in this forum and make it public. This maked the project already much better to this point.
Here is a much better explanation of why and how i want to use the HitZones
Basicly i want to use the „iHitZone_X" variable for the different damage states.
- iHitZone_1 = 0; equals Damage_State_1 - no damage taken at this point
- iHitZone_1 = 1; equals Damage_State_2 - damage taken - Flesh shooted down
- iHitZone_1 = 2; equals Damage_State_3 - damage taken after Flesh shooted down -
Dismember hitted part (and below)
This is why i combined a few colliders to a single HitZone. I noticed a few times it is hard to hit the lowerarm_l/r. More often i hitted the hand instead. So i put them both togehter, this way just feels better to play.
I already kinda at the limit with the instructions for the material. If i would use another predefined mask for the hand also i would need another texture. I think It is just not worth to do this for the hand.
The easier way is just to have something else in place to drop the hand of the body and rip of the flesh from the lowerarm (like spawning or similar).
In the image you can see what i meant with “easier to expand”. Just add a new number to call then another state with the function.
Edit:
Here is a first view at the first damage state test for the hitzones. I dont like the legs, this looks just to strange (the used physic, not the bones they are more like placeholders at the moment).
Also i need to find a performant way to exclude the hitted parts. As it is now i use to have a short amount of time where i set physics with a timeline to have little variations to the animations. But this also resets the whole physic of the enemy.
Dont want to use a loop or checking variables in the timeline, just not sure how to do this otherwise right now.
Maybe i get rid of the phys animations after a hit. The people i asked does not see a difference. So maybe it is only worth doing this for dead animations.
@Roy_Wierer.Seda145 Was really a good idea to make it kinda goofy and it is room to tweak the look of it. I like it
2 Likes
Exactly I moved away from BP to c++ and only keep BP for the UI designers (UserWidget) even those I’d rather have had in JSON or something lol. These days even prototyping goes faster in c++ honestly.
1 Like
While testing the damage states i notices something about the head what really bothers me now. This just looks so much better and intensiv then the normal head if the zombie is running to you. I need to find a half logical way to make this visible more often.
After thinking about this it almost feels like it would be wasted to only be shown a split second with a headshot.
I think one of the better ways to display it logical without killing the enemy instant would be using this with a helmet, so shoting down a helmet and half of the head. Not sure but this could kinda work because this way it could make you think you did not hit perfect.
Maybe color coding a helm as a base rule, so you would know with the helm color you would need at least shoot twice to kill the enemy.
A video about some tests i did:
- Damage states
- Points for dismembering
- Triggered Niagara blood impact effects
- Physics activation after bones broken
- Dismembering
The idea the damage states:
- If for example the upperarm is broken the enemy cant attack any longer with it.
the same count for the legs, if one is broken they cant be used for attack. - If only bitting is an option they enemy would be easy to hit if close and attacking, because the head is much more easy to hit then.
Not sure at the moment how to handle the belly. It is really to much for a bullet from a pistol. As the system is driven by impact force this could be used if the pistol for example have more impact strenght. But this would work perfect for something like a shotgun.
The second state for the belly would rip the body in two parts then. This way it would also make sence because there is no spine would holds the body togehter.
Another step to get the gore system finished. All functions work now the way they should (was not really fun to change from 1 to 2 states).
I set up very quick a scene that would look more like finally ingame. Wanted to see how this will look like.
The additional Niagara blood effects are more placeholders(just a test if get triggerd), also i created only the left arm parts before i am not sure i really use it this way.
2 Likes
Good stuff all that remains is the finetuning. I love how the underarm pops off this is really smooth. I find the skull parts a bit lightweight looking they fly all over the place, maybe they need more mass, but given how the impact damages the body it does fit the overall damage visuals. I’m not too sure yet about the stomach, the rib bones are very clean looking all white and not broken, you’d expect them to be damaged and bloody by default when visible.
Sorry I just had to, I thought of the regenerador bite :') how they just do a magicarp flop at that point.
Actually they have a system there too also in the original RE4 where you shoot organs on those things
2 Likes
Yes this is a good point. I was also thinking about this, it is a little strange, it seems like the moment you use time dilation the force works much stronger.
Not really sure what causes this at the moment.
Another thing i was thinking about is using less parts for the “head explosion” sometimes. So basicly having a few random selected then.
And also for now i skip the idea of the headshot with closeup and slow motion, this just feels wrong in this kind of games and breaks the gameplay to much. Maybe i come back to this later and add this back in as an option because it is just fun to watch.
Here you can see the difference - with and without time dilation.
I did not change it so they are still basicly placeholder. I am just not sure with this also how to use it in the end. And having organs flying out of there is sure a great idea. This will be added later because it is not part of the main model so it needs to be spawned or attached anyway.
2 Likes
After cleaning the code after all the tests, renaming all the variables to be more clear to read, fix some hit zones bugs for the damage system it is finaly finished (for now ).
I will stick with the 2 stage damage system, so it is better to read what you see.
Only need to figure out how to display the headshot states if i really use two. And how i handle the impact in the belly.
Before i go over to build the gore models, i did again a test with Nanite models and polypaint (I just have to get this to work somehow/somewhere).
Here is another video about a short test flytrough to look for deforming:
- Only 3 different stoes used
- No UV´s
- Polypaint only
- Each stone is ~500k polys
- Disk size each ~ 50MB
This test worked really well. The insane part of it: This are ~ 300 stones wich means this is ~ 150Mil polys. It is really insane how much Polys you can use without running into problems.
I did not notice any deforming, the colors are pretty simple though, but it works. Seems like this could be a perfect use for something like Houdini (wich i did not test only read about) for random variations.
Using this i guess ~ 15-20 stones would be enough to build a whole building or even a castle. If you set yourself some rules about the size you could use for more difference all 4 sides of the stone so this would be the look of ~ 60-80 stones. Did not even try Vertex Paint inside the engine for more variation directly.
After this test i know i have to test something with this. Would also work pretty well for some parts of my levels.
Edit:
After building more stones and build a wall with them this seems really to work for such things. The wall is not build very well, i am still just playing around with possibilities to use polypainted Nanite models to save shaders and textures.
I wonder if someone could figure out how many different stones are used for this wall.
1 Like
An update for dismembering again, damage state 1. Slowly it comes close to only needs fine tuning to be finished.
3 Likes
Gore Update. I think this is almost how the dismembering will look in the end.
Some things are still feel wrong. (i need not update the blood maks this is why the wounds look so clean)
- Like the bones after cut of the lower arm of look a little to big
- Shooting only 1 time in the belly possible
I think i need to do damage states for the belly also.
I guess the first would be to close the hole in the middle picture. So only front impact and base on this a hole.
1 = first damage, 2 = combine and cut the middle of the model (like the middle picture only without the side so basicly just stick togehter with the skel) 3 = rip the body in half.
Like i tested here:
Edit:
A very short gamplay test to get a feeling how playing with the new gore would feel like. I think if it is finished this could be the most fun part of the game, and one reason to play it again just to enjoy watching this.
Video inside
(Die to Survive - Gore / Splatter FX Gamplay test - YouTube)
2 Likes
While fixing some errors with the calculation for dismembering i created something usable almost by accident.
I was building for debuging pourpose a display for the points at the hitted location, but as i played i thought this could also look pretty nice in arcade mode or for hunting points for leaderboard. So i worked a bit more to make it look a little more usable for usage in the game itself (still WIP).
2 Likes
DTS Gore’s System is very advance. I’m taking notes! That’s a very nice Visual Touch and core to the roots Video Games…Scoring. I miss the ole days when all you had to do is get the Highest Score and the only reward was Bonus Lives. Haha
A lot of cool game play features are hiding Debug systems. That’s how V8 SUPERCAM came about. I have a couple of other subsystems that have evolved out of Debugging Systems. One of my favorites takes basic debug log with markup. It allows me to translate 3D interaction and events into Text that can be used for additional game play formats.
2 Likes
Thank you @TechLord, yes the gore system gets slowly to how i wanted it to be.
I also miss the higscore hunt often in games, this is the reason why i want to do some sort of online scoreboard so people have always a reason to play again
And because i like to see the points, i build a more advanced version and made also the multiplier visible there. This feels really just more satisfying and responsive even if i only plaing around at the moment. This will definitive be in the game as an option to turn on/off.
2 Likes
Multiplayer is definitely worth consideration, even if is only Local Split Screen. House of the Dead was my Fav in the Pizza Parlors. And, it was more fun when a Buddy was on the side, shooting Monsters with you. I’m definitely implementing Multiplayer in my Railshooter.
Scoreboards --> Leaderboards --> Tournaments
I implement some form of scoring in every game design. I even added Scoring Functions in V8 SUPERCAM to be applied as Score Multiplier based on the Distance/Angle of the Camera to the Avatar Body when performing actions. A simple and elegant way to implement the System as a Game Mechanic.
Interestingly, I designed a Cash-driven Tournament Management System for Tournamentblitz.com back in the day before Esports was called Esports. Any Game with a Best Score mechanism could use the system. Both Single Player and Multiplayer Games.
Players could purchase Virtual Tokens though any Webpage with a Paypal Button. Haha. All powered by a HTTP Server running PHP. However, it was not very secure from Cheating, so I had to take it back to the drawing board. I have not been able to get directly back to it yet, but, I will most definitely. It is the reason I started to learn UDK & UnrealEngine to the first place.
My ultimate goal, is create Action Adventure Treasure Hunts for Real-world Cash in Beautiful 3D Worlds for Desktop and VR. I could have never imagined Today’s Graphics, Animation, Physics, Audio, AI and processing Power.
2 Likes
Multiplayer i was think a lot about. But i decided to gp single player as i thought playing on pc with mouse would not make sence have multiplayer as it is no fun with gampad to play a second option.
Now it is different because of lightguns also. The problem is if i would change it now it would break the whole systems like movement, damage and much more.
The problems ...
Change this to multiplayer is of course possible, but this will need a lot of time to make all systems work togehter the right way. So the first version will only be single player as i anounced it. But i will also of course do try how i can change this to make it work for multiplayer. But if i really do this then this will be an update after a release.
Just takes all to much time and i want to do the gore as close to be perfect as i can do it.
Still woking on it, one of the most i struggle with at the moment is the belly. Just playing around and test how the best way to use this. Not sure if i attach and simply hide it. Or attach it and use master pose. 1 model would work simple, but as i want now also damage states with cutting in half in the end it is getting more complicated.
Still prototyping the inner gore.
3 Likes
I’m thinking the gore sys looks good as it is. I’m easy to please haha. You could probably change the shade/color randomly to avoid visual repetitiveness and that can be done in the material cheaply with a simple node, otherwise your particles and slo-mo can cover a lot of visual appeal …
I concur with your position. MP retro-fit mid dev is bad idea...
I concur with your position. I would never recommend retro-fitting Multiplayer mid development. It requires implementation at the construct level (functions and variables) so it requires some planning.
If its your first go at it, there will be a learning curve and massive amounts of Testing and Debugging along the way. If i was to make a recommendation, it would be to implement Multiplayer upfront in a new IP.
2 Likes
Thank you for the video @TechLord .
This is kinda the perfect moment for something like random approach for textures. I just wanted to do anything else and startet today to redo the meshes for the greaveyard.
I have build quite a while ago around 40 different tombstones with also the same ammount of stones as sign for it to mix them together.
But the textures that would be needed is just not doable. I have also crosses and lot of other stuff to have a lot of randomnes. So i started to redo all the UV´s, if they the order is right it is possible to get away with only 1-2 materials each for the base colors and a mask for dirt and moss or similar. I will also try again polypaint, maybe with simple colors it is not notable as much.
Random masks would be perfect. I will try this tomorrow. I need to rebuild a lot of models to use it this way.
40 different Tombstones is a lot. I think in terms of modularity. Could probably split the Tombstones in 4 horizontal interchangeable sections Top/Mid/Bottom/Base with 6 different styles. With this method you could generate 6^4 = 1,296 mesh combinations
A Seamless Base Material can provide a plethora of visual aesthetic for uniqueness. Would keep them High Def and let Nanite and Lumen do their Job for lighting/shadow.
