When I came across kenney's tank asset pack and the new phaser version 2.2.0 I got a little sidetracked and instead of continuing the work on the dungeon crawler I made a little tank shoot'em'up last weekend.
Phaser is really great for writing 2d html5 games and it reduces the work required by a lot, since it not only manages all sprite related things but also comes with integrated physics.
Here is a new video showing off the wizards with their fireballs and the bats that are now available as enemies in the dungeon:
New in this video are also improved the combat animations for the main character. Instead of just moving the hand (and the weapon) now the whole character is animated to improve the feel of combat.
Every attack now has a range of damage, a critical chance and a critical damage percentage.
The combat texts have been changed a to better reflect what is going on: damage to the player is now red with a minus sign, damage to enemies is white and cirtical damage is yellow with a slightly bigger font.
Things planned next:
- new textures for the dungeon (reducing the amount of 90° angles drastically)
- objects like: barrels and health pools
- combat skills (I am thinking along the lines of swipe, stun, whirl, jump)
The wizard is now ingame and can attack the player with fireballs.
wizard casting a fireball at the player
The fireball itself is a blender model (a half sphere with a cone shaped tail) and it creates an alpha blended sprite every few frames of travel. These sprites have one of three random colors and fade out over half a second.
These sprites (and also the combat-text sprites and the hit-effect sprites) are never destroyed but kept in an array and the next effect will reuse the first currently invisible sprite and only create a new one if no unused sprite is available.
I was looking into three.js particle systems (which are now actually named point cloud) for the animation effects - but in the end I went with simple sprites because it's easier to handle. The amount of sprites can be increased on the fly (this is not possible with point clouds) and also the amount of particles/sprites needed is so low that it does not (yet) matter performance wise.
From the start of implenting games with javascript in 2013 I did not like the lack of precise auto completion in webstorm. Of course this is not webstorms fault, there is just no way of knowing what to auto complete without typed variables.
Another annoyance: small typos in javascript go unnoticed until the code is executed and even then the behavior sometimes is just strange and the error is not clearly identifiable.
This might be fine or at least tolerable for small scripts, even small games. But I already got fed up with it. (Especially because I see what intelliJ (and therefor webstorm) is capable of with its indexing power, code completion and refactoring when I edit the Java code at work.)
The solution seems to be typescript. After reading up on it I just started converting the game and it's going fine so far. My biggest javascript file (the "dungeonObject") is already converted into typescript, and with some minor modifications (and minor bugs) the game can already be played again. (Even though the rest of the code is still pure javascript.)
A quick example of one of the benefits:
yay, typing!
Webstorm can tell me this, because the array is declared as:
export var clickableMeshObjects:THREE.Mesh[] = [];
I think this will be very helpful and enable me to find many errors without even having to start and test the game.
This morning I was not in the mood for coding, so instead I grabbed the avatar character model and modified it to create this wizard and thought I'd quickly show it to you:
evil wizard casting something
This also nicely sets up another coding goal. Since the wizard is clearly casting something, I will need to implement projectiles into the engine. In the case of the wizard I am thinking fireballs, but projectiles will be useful for arrows and other stuff, too.
This post was the first time I wanted to export a blender animation to gif.
Here is how that works:
render the blender animation into images (the default directory is c:\tmp)
load the images into a gimp project (as seperate layers, simply drag & drop all of them into the layer box)
change the image as needed (for example I cropped it)
run filters - animations - optimize
export (check "as animation") and choose a name ending in ".gif"
Since the first video I have implemented some new features that I would like to present today:
The enemies (for details check out the last post) can now be targeted (the current target is highlighted) and you can interact by clicking on them. Interaction in this case means, you hit them and they hit you.
The hitting is visualized through an attack animation which moves the hand forward and rotates it nearly 90 degrees. Since the weapons are attached to the hand-bone the weapon appears to be swung.
There is no visualization for the impact of the weapon yet (I will try for some kind of blood particle effect later), but the damage is shown as a number that floats up and fades out.
The combat right now is very static, since there are no damage ranges, evasion chances, blocks, different attacks, skills or projectiles yet. I will have to come up with a fun fighting system once all the basics are in place.
The death of an enemy is animated too, they fall backwards and then sink into the ground.
Since the enemies are just a differently textured clones of the player we have the same animation for the player dying, minus the sinking into the ground part but with an added "lights out" effect (as seen at the end of the video).
I am working on a bat as a second type of enemy in blender:
And I am also coding a quick way to define dungeon layouts so I can start to test bigger dungeons.
So stay tuned or more updates.
So for now I introduced this guy (and some friends):
evil clone
They are of course quickly reskinned versions of the player avatar. But they do the trick for now.
Making them move towards the player was easy - because the player could already move towards a target. For the enemies the player is the target (instead of the cursor).
Collision is more interesting: It doesn't look very good when the enemies run through each other and through the player. So now every object (enemies and the player) has a collision radius.
It took me this evening to figure out how to handle the collisions exactly - first approach was to just stop movement as soon as the spheres overlap any other sphere. But this way both spheres are stuck in each other.
Improvement one: Not only stop, but also move back the last movement. (substract the movement vector from the current position). This way the spheres stay outside of each other.
This kind of works, but as soon as there are more enemies than one approaching from the same direction, the first one reaches the player, the second one stucks himself behind the first one.
I played around with different ideas, calculate the angle to the target and to the collision target and trying to figure out how to move the enemy around the other. But I had to throw stuff away again and again, until I came up with this simple solution:
var collisionDirection = collisionObject.position.clone().sub(this.position);
collisionDirection.normalize().multiplyScalar(this.speed);
this.mesh.position.add(this.speedVector.clone().sub(collisionDirection));
Instead of subtracting the complete Movementvector in the case of collision, I only substract the "part" of the vector that goes into the sphere. This way (if the enemy does not plan to go straight through the sphere) there is still movement and it looks like they go around the sphere.
The effect will be demonstrated in the next "show-and-tell"-Video.
As a small teaser, I leave you with this:
Yes, there is a leaf on the stick and yes this was a request by my wife.
