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

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:

http://jppresents.net/static/birthday/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...