ludum dare 31 - one more small distraction

The last weekend was a ludum dare weekend and I decided to join the fun.

I created a small tower defense game titled "Stop Christmas".

It's using phaser & html 5 and you can play it here.

Ludum dare is game jam / competition in which you have 48 hours to create a game matching a given theme. The theme this time was "whole game on one screen" - my tower defense matches this, but not in a creative way. You also have to create all the assets (graphics / sounds etc.) yourself in this 48 hour window.

I was using the "unofficial" theme (which lost in the last round of theme voting) which was the unicode character "☃". This is why the enemies are all snowmen.

You can build and upgrade towers and the remaining health of the player is visualized by "how cold" it is.


a little sidetracked: tank wars

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.

It ended up at 600 lines of typescript and you can play the result here (for free in your browser).


combat against bats, wizards and those hammer guys

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)


first projectile: fireball

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.


Typescript incomming...

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.


enemy wizard character model

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"


new dungeon crawler features: enemies and combat

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.


enemies and collision

The dungeon crawler I showed to you in the last post is still missing many vital parts, one of them is enemies.

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);

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.


three.js dungeon crawler

This is the first post about the game I am working on. At this point I plan to make a realtime dungeon crawler with hack n' slash combat. It's going to be a browser game that requires no downloads to play.

This video gives a short overview what I got so far:

To recap:
- two dungeon textures (groundfloor and wall)
- dungeon tiles (consisting of three tiles, ground, ground with one wall, ground with a corner)
- character texture
- character model with two animations (walking and idle)
- ground collision for the player
- custom mouse cursor, ability to detect clicks on the ground and visualize them
- player movement (toward the clicked target)
- different camera angles
- a test-weapon that can be attached to the players hand

I plan to create everything from scratch, which means only using assets I create myself (possibly with some artistic help from my wife) and to use only "basic" libraries not full game engines.

So far I am using:
- three.js for the graphics
- tween.js for all tweening needs (right now only the camera position changes)

I'll keep you posted on the progress here - and of course once there is any real gameplay I will link playable demos too.


blender + three.js + bones = animations

On the topic of animations using bones in blender and exporting them to three.js:

Remember this: Never set the exporter to any align (this took me 4 hours to figure out), always align "none".

Three.js Exporter Options

Because: It will mess with the rotation of your bones while being animated. (In blender everything looks fine, and in three.js everything is fully out of whack.)

From what I figure: The exporter moves the whole model (and also all bones) if the alignment is changed while exporting. (So far so good), but the pivot points of the bones are *not* moved with the rest. This way, if an animation rotates a bone it now rotates around some point, but definitely not the position it rotates around in blender.

I found some pointers to similar problems in this question on stackoverflow and while the answers were interesting and gave me pointers, seems nobody had the alignment problem I had.

The tips form stackoverflow are:

- Delete the armature Modifier before exporting

- Checked the Vertex Groups

- Keyframes for ALL bones at the start and end of the animation

and my tips:

- Don't export with any alignment active in the exporter options

- Select the first action under model and under armature in the scene graph, and have the armature selected when exporting (not doing this led to another export error, where the action names are correct, but the action itself is a copy of the one before it)

All in all the exporting seems to be a very delicate process.

Why I had set the alignment to center is another story - it's about how I export the dungeon-parts and will be covered in a later post.

(Three.js & blender exporter Version 68)


getting started with 3d: three.js + blender

I made the decision that I want to create a game in 3d.
This was three weeks ago. Since then I have made these technical decisions about the basics:

- javascript
- Blender for all modelling
- Gimp for all textures
- Webstorm to code it in
- three.js as the webgl library

Blender and 3d modelling in general is completely new to me, so I have been learning the blender basics for the last weeks. Also I have never programmed any 3d before, so getting to know three.js was also a challenge. I have used javascript/webstorm and gimp before to develop 2d-games, so at least those aren't completely new to me.

The reason behind the tools: Blender & Gimp are simply the best free tools available I could find. They also offer most of what the major (and pricy) products can do.
I decided on javascript, because I like the idea that no download is required for the game and it runs everywhere (where webgl is available) and also because I want to learn about programming the 3d parts of the game and not just use an engine like unity.

The first "released" results, a simple buttefly I modeled and animated in blender is displayed using three.js:

three.js butterfly
It's a virtual birthday card and not directly related to the game, but it was a good starting point to get to know the tools and evaluate them.

More about the actual game in the next post...