Woah. Friday already? Seems like I was writing last week’s blog yesterday. Geez, time really has a way of sneaking up on you.
We spent this week very focused, touching up several bugs mostly, and working on the trailer.
Here’s a list of what we did this week:
Completed the implementation of ladders in the game. Before this week, ladders could not be added at runtime, which meant that they could not be created in the build, and could not be placed by Bricktrons. But now, ladders can be created and destroyed without divine intervention. Hurray!
Arrows now stay attached to the characters when they hit. The arrow detects the closest bone in the skeleton hierarchy of the character it hits, and parents itself to that bone. In effect, the arrow seems to lodge itself on the character, and now moves accordingly. Since the target has a tendency to die in the process, we made sure that the arrow stays lodged in the ragdoll as well. This gives some interesting headshot moments, but on the other hand, makes the game slightly less kid-friendly. We will probably add an option to remove those.
Added a rudimentary facial animation system to make the Bricktron more expressive. Right now, they can only blink and frown when they get hurt, but eventually, we would like to make them express any kind of feeling, and perhaps even talk, who knows?
Started experimenting with shader programming. This is not part of our short-term goals, but we expect that we will need to dabble into custom shader programming to get some specific things done.
Made significant progress in the filming of the trailer. One scene in particular was very troublesome: a 30 minutes timelapse of a large castle being built by a small army of Bricktrons. For the entire duration of the scene, we could not intervene, and any significant bug would ruin the entire shot. At 30 minutes per shot, I can safely say that this scene gobbled up several of my days. The result, however is pretty spectacular, and I consider it as the centerpiece for the trailer. I can’t wait to show it!
Tile mapping basics
I was in an interesting conversation last Wednesday with a friend of mine while attending the Mount-Royal Game Society monthly meetup. We were discussing different ways of creating tile mapping in games. We came to the conclusion that, while several methods exist, only a few are truly efficient if you do not have access to layers with transparency.
In a 2d game engine, it is exceedingly easy to create terrain transition because you can overlay textures with opacity maps, and generally do not have to worry about taking into account all the neighbour tile possibility tree.
However, in a 3d game engine, unless you have access to custom shaders, it becomes a real challenge to limit the number of possibilities to a reasonable amount.
The current method we use comes with a rather large number of limitations, but happens to be very lightweight and extremely simple. It is called Bitwise tilemapping.
Inside the red square is a Grass >> Sand tile transition.
I was very fortunate to stumble upon a very good tutorial on this technique when we started developing Castle Story a while ago. But I will attempt to explain it in my own words.
The first thing you need to know about tile mapping is that if you plan on taking diagonal neighbors into account, expect to have a very large possibility tree. Counting diagonals, there are 8 neighbors in a square tilemap. Assuming there are only 2 types of tiles, that means there are 256 possible transitions – waaaaay too much if you plan on drawing those by hand.
That’s a lot of possibilities.
However, notice that I highlighted the few tiles that only take the adjacent neighbour into account : there are only 16 of them. That’s a LOT more manageable than 256, don’t you think?
Allright so let’s say we only have 16 tiles, how do we select which one we should show? This is where the bitwise method comes in handy.
Basically, we check the 4 neighbours one after the other. The order in which we check them is not so important, but let’s say we check them in a clockwise direction, starting from the top. If the neighbour is of a different type than our center tile, we write 0 in our list. If it is the same as the center tile, we write 1. It is important to always write from right to left, because once we are done checking all 4 tiles, we end up with a binary number.
This binary number can then be converted into decimal notation, and we end up with a tile number. This tile, if drawn correctly, should correspond to the shape we are looking for. However, drawing tiles is an art, and this is another subject that is worthy of another tutorial. Maybe some other time.
So, bascially we extrapolate the process to every single tile in the universe, we should end up with something that looks good.
In 3d, it’s a bit more complicated, neighbour tiles can be in any direction, as long as they share an edge. We spent a significant part of our first year of development working out the intricacies of detecting those tile transitions, and applying the right texture mapping to our voxels.
Anyway, that’s pretty much it. I’m not very good at writing tutorials, so I really recommend reading the tutorial I mentioned. It is much better than my own. Anyway, try it yourself! making tile based games can be really fun!
Soundtrack of the week
I have this song in my head. It won’t go away. The cure? Listen to it until you find another song.
Try to guess which one that’s stuck in my head, it has the word “the” in it.
Thanks for reading!
34 Comments for Dev diary number seventeen : Bitwise Tilemapping