Wow! Lo_oks fantabulatsic, man! If its not a huge pain, twitching bodies would be ultra cool. Can’t wait to play this when it’s finished!
particle-splat_system.blend (631 KB)
Here is a quick n’ dirty prototype for a blood particle emitter. It spawns in blood particles with a fire-and-forget sort of style. The individual particles have a splat function which triggers when they collide with the floor.
I will probably want to expand this to also splat on walls/ceilings (so things can get really messy). Keeping the blood splats small like this will hopefully minimize the chance of a decal going over the corner of a wall (causing it to stick out into empty space and look bad).
These can be combined with ‘gib’ particles that could be unique per-monster, to give satisfying results when ‘over-killing’ a monster (doing a certain amount of damage past what is needed for the monster to die, resulting in a shower of body parts).
particle-splat_system2.blend (637 KB)
Well that was easy.
Blood particles now cast a ray on collision, in the direction of their velocity, and aligns the corresponding splat to that ray’s hit normal
I also added a lot of random velocity to the blood particles, to make it fly around more and hit all the surfaces, and a mouselook so you can better see what’s happening.
(I also tweaked it so the splats actually sit on the surface, and not like half a BU above it 
)
It has been one of those days where stuff just goes smooth 
I got kind of excited and had to record this real quick:
Along with the blood, I’ve also added a bit of ‘kick’ to the player’s camera angle when you’re hit.
The severity of this is factored by the amount of damage you’ve taken divided by the amount of HP you have left (which is why you can’t notice it much in the video, the zombies are barely making scratches).
Cool!
Keep up the good work and try to get motivation also in next things which to implement so that you can finish this soon with a big smile in your face!
So cool, this blood looks retro and awesome. Keep up
Awesome.
If you want some more enemies tell me the specifications and I can render some out for you, or I can put the models somewhere where you can pick them up. There’s a few in my collection which would look good as 2d sprites: http://pickledtezcat.deviantart.com/
They’re part of a project that I’ve been working on for ever, but never seem to finish. It would be nice to see them find a home…
Wow! Can’t wait to play the finished product. Looks better than DooM!
Test shot for a re-vamped zombie. He has a little more character to him now.
(he needs to be re-animated at some point anyway…that was a zombie joke)
I really have to make that blood look like radioactive ketchup to get it to show up in the low-res render. So anyone wanting to comment that ‘the blood is too red’, that is why 
Re-animating is deffinitely a good idea. He turns too slow making easy to flank him and crush his skull. His hits are slow, too. Right now he reminds me of the Heavy Gunner from warface.
Looks fantastic! I think you should add a bit more frames to enemy animations, like in Hexen 1. So they can move faster and movements are more recognizable. I know it is hard work, but enemies(animations) is what player will see constantly throughout the whole game.
And maybe start the game without mipmapping…it will add nice feel to the retro look.
Great job!
Haidme: The enemies in Hexen (at least the ones that walk) do have a 4-frame walk cycle. The difference is, their animations are great, and mine are not. Not yet 
Here be the Ettin (the most common critter in Hexen). Four walk frames, three attack frames (mine have 4), one pain frame, and 9 death frames (one normal, and one over-kill) (mine has 12), along with a misc. ‘gib’ (the morningstar at the bottom). Some of the entities (like the Wyvern, and the player characters in the class selection screen) only have a 3-frame walk cycle.
Hexen is the prime source I looked to when determining my boundaries for sprite production 
I love this game to bits. It’s one of the central sources of inspiration for the visual/aesthetics I’m going for (the other biggie being Diablo).
But, looking at the game play of Hexen, you notice the enemies do not slide smoothly along the ground as they move; the translation of the entity has an element of choppiness which I believe makes the animation look more natural.
Looking at my game, the zombies, although they move slow, slide across the floor like they’re on roller skates. The more I see it now, the more goofy it looks. Perhaps the enemy movement could be reduced to straight worldPosition changes (after rayCasting for obstacles first, of course), to give them that choppy movement.
I also think that my framerates are still too slow. I have been tweaking them and stuff is running a little faster as far as frame progression.
As far as making the Zombie move/turn so slow…mostly that is for testing purposes (I want to easily be able to flank around them to see how the multi-direction animations are working together, and so on). I am simply not to the point yet of balancing the enemy properties into a real, playable thing. I am just setting them to what I need to test what I’m testing.
Perhaps I’m falling into the trap of showing off too much stuff before it’s done, haha.
Thanks everybody for your feedback! Stay tuned for more, as it comes.
Ok I understand.
I think the slower the enemy moves the more the frames should be. An enemy like Ettin moves fast and it does not need more animations to look smooth, however if you want to make a slow moving zombie, you need at least the twice the animations of the Ettin in order to make it look smooth enough. I had the same problem once with a 2d sprite base game and that was my conclusions about animations.
P.S. On contrary, you are not showing too much of the game.
I still don’t see quests, pickables, sounds/voices, hud design, environment/levels…
Keep it up. It looks great so far!
play walk animation, set frame property
use frame property
to pulse forces during x frames
(I dont know how well this will work for four frames though…)
I have successfully, as far as I can tell, implemented the ‘choppy movement’. As I though above, this really makes the low-fps animation look much more natural.
(one thing I should put in is a randomization to each sprite’s frame timer a bit on init, so everybody isn’t stepping/moving in perfect sync).
@BPR: My sprites do not use blender’s animation/action system, but it is run through a python class which holds the sprite’s current frame #. The entity’s AI component tracks its sprite’s current frame. If its stored frame # does not match the sprite’s current frame, worldPosition is shifted, and tracking_frame is updated. This way, an entity ‘steps’ forward by a factor of their movement speed, every time their walk animation frame changes.
I was worried that this kind of movement would be hell for collision, but so far I haven’t seen anybody get stuck in walls or walk through each other or any of that nonesense. Finger’s crossed, and moving on.
def advance(self, mod=1.0):
"""Move our object forward at our movement rate, multiplied by mod"""
obstacle = self.sight_ray(1.25)
if not obstacle:
new_pos = self.owner.own.worldPosition + (self.owner.own.localOrientation.col[1]*(self.owner.fighter.move_speed*mod))
self.owner.own.worldPosition = new_pos
else:
if randint(1,10) <= 3 and 'ent' in obstacle:
self.target = obstacle
self.state = 'attack'
EDIT: Re Mipmapping: I do have a script running which disables mipmapping. The combination of my ‘super-fast’ compression of screen-capture coupled with youtube’s compression does a lot to hide this though The pixels look much crisper than they do in the vids.
To show a bit that’s going on under the hood, here is a mock-up of what my entity class composition system should look like once more elements are added into the system. For now, only a few of these classes are real, but many of them are planned…
Any object which has any kind of dynamics becomes a Thing. The Thing class holds the most rudimentary info (world position, facing, and a few other little things). As attributes of that Thing class, we can plug in any of the ‘components’ from the next step in the tree, and so on down (up?) the tree for each branch that has options. For example, a zombie is a Thing with a Fighter, a Sprite, and an AI. Your weapon will be a Thing with an Item component, with an Equipment component on the Item, with a Weapon component on the Equipment.
As these sub-components are defined (if they’re defined), an ownership tree ties everything down through to the base Thing class. Now, you can access any part of any component of an entity from any other component of that entity. Complex objects can be made using small, concise little bits of easily-organizable and totally generalized data structures. New components can be shoved in fairly easily, as well as be taken out, so the project remains agile, and can stay stable through the process of having its own guts re-arranged as things are developed.
Some exciting new additions today:
-Introduction of a new entity, the Life Potion. This also brings in the new Item thing component.
-In order to have use for the potion, a ‘use’ command has been implemented (you will pick up items with a command, rather than running over them to grab them).
-To make this work, a ray is now projected from the camera to pick up Things as targets. The HUD now has some text in that black box at the bottom which reports some info on what you’re currently ‘aiming’ at.
-For now, picking up the potion will simply restore some HP before the entity is killed off. In the works will be a system where you can store potions and use them with another command.
Also, I did a little optimization to the blood splatter code. Now, if a blood particle lands on a blood splat, it will end that splat and replace it with its own. This A) greatly reduces the number of decals in the scene, without putting a lifespan/cap on the number of decals, and B) greatly reduces the amount of z-fighting (flickering artifacts you see from overlapping faces).
I also wrote this awesome little method to find XP points needed to reach level L, using recursion and a couple global values:
M = 50
N = 100
def XP_to_lvl(L):
if L == 1:
return 0
else:
return XP_to_lvl(L-1) + M + (N*(L-2))
Speaking of stats, I am going to soon be making the combat more RPG-ish. Monsters will have Hit Dice, Damage Dice, Defense, EXP value, etc.
The one RPG element I will not have is ‘to-hit rolls’, or having a weapon hit/miss based on dice rolls. Morrowind taught us all how crappy that is in a FPS environment (we still love you though, Morrowind!). Like Oblivion and onward, if you connect with an attack, you hit. If not, you miss.
The attacker will have an Damage roll which will go against the target’s Defense roll. Those with higher defense take less damage, and those with high attack deal more damage. Pretty simple.
Weapons will soon have a form of ‘power attack’. In Hexen, the initial weapon of the Warrior (the Gauntlets of He-Man Punching or whatever they are) have this; each time you strike an enemy, a ticker goes up by one. If you swing at anything but (including swinging at air), this ticker goes back to 0. On the third tick, an attack on an enemy will initialize a power attack, which has a special animation/sfx, does more damage, and pushes the monster back a little bit. Something like a skill-based critical hit system.
That’s sound good.
I really like see blood everywhere, may be instead of making disappear the old blood splash you can replace both by a bigger one.
I fought for a couple hours today with trying to implement stairs into the dungeon generator. I came up with a couple ways of trying to determine which tiles could be valid for a stair tile. But I cracked it when I realized it only has to follow one rule:
-A stair tile can only be placed on a wall tile which is adjacent to only 1 open tile. If it only has 1 open neighbor, we know there is only one direction you could enter the future stair tile.
So all walled tiles are checked, and a list of candidates are compiled. Two of those candidate tiles are then chosen at random; one is given stairs going up, the other stairs going down. Easy sauce.
(only problem is there’s no control over the distance between the two stairs…they could end up right next to each other!)
I also worked in lluc’s idea, and gave blood splats that erase other splats a larger scale. This does help keep things more bloody without hitting performance, nice idea!
I also wasted some time doing clean-up on my code, adding comments, and fixing some debug output hell situations that would come up far too often.
It is late, so I will sit down and maybe do another video tomorrow.
Today’s Updates:
-Put together the skeleton of the top-level menu system that will drive the pre-game.
I was planning on using BGUI (or eventually KXGUI) to do the menus and stuff, but I find building these things with objects and logic bricks much easier. These menus are doing nothing complicated, so the thought of having to script them all out seems a little pointless, at least at this point.
I have found a font that I really, really like; Black Knight’s Quest. This will probably over-ride all existing text in the game so far. It has a very Diablo-esque vibe to it, without being a rip-off of it, is “100% free”, And it is readable! (unlike the olde english style I was trying before).
The title format is a lil’ nod to Dwarf Fortress. The gold-colored ‘sub-title’ is randomly generated. Eventually, this subtitle can be generated after defining a seed for your particular game, so each game/run through the dungeon will have its own unique title. Same can be done with things like the name of the dungeon (I will bring in the Skrubble module from No Sky to generate proper names)
I have also started implementing the sound effects. Again, I am ditching trying to do this through script, and opting to use brick-work to handle the entity’s sound effects. So far it’s working well! Each entity has a property ‘sfx_sound’ where sound is ‘hit’ or ‘swing’ or ‘die’ or whatever, which triggers the sound when True, then triggers a property actuator to kick it back to False. The logic then makes whatever entity’s sfx_ property True, to trigger that sound.
Sounds now include footsteps when the player walks/turns, a swoosh when you swing your mace, a fleshy impact when you or a monster is hit, a death sound for the zombies, and even a little splish for when blood splats on a surface.
I said I would record a new video, so here she is. Just a quick run through a tiny dungeon.