Because Dragon Attack’s performance on Crafty.js was disappointing, and the libGDX port also had problems running smoothly when compiled to JavaScript (plus some unfortunate technical decisions I made along the way), I’ve decided to go for a third rewrite, using better tech. (“Rewrite” sounds worse than it really is – we’re talking about a two-day Ludum Dare project, after all.)
This is the third and final part of a series in which I explain how the artificial intelligence works in my latest game, Twistago. In case you missed the first or second part, you can catch up on them here and here.
At the beginning of this year, I posted a set of goals for the first half of the year. The idea was that a public commitment would help me stick to them. With that period behind us, it’s time to see how I did. Ranked on a scale of 0 to 1:
This is the second part of a three-part series in which I explain how the artificial intelligence works in my latest game, Twistago. In case you missed the first part, you can catch up on it here.
This is the first part of a three-part series in which I explain how the artificial intelligence works in my latest game, Twistago. The AI has three different levels: easy, normal and hard. This is also the order in which I developed them, each level building upon the lessons and code of the previous, so it’s only natural that I do this writeup in that order as well, starting with the Easy level.
As I alluded to in a previous post, Mystery Game No. 1 is no longer a mystery. It is called Twistago and it’s the best thing since… well… the second best thing! I actually pushed the button for global launch almost two weeks ago, but didn’t have time for a proper announcement until now.
Always new things to learn! This week, I integrated Facebook highscores into Dragon Attack, so you’ll be able to see your friends’ scores and challenge them to beat yours. I’m hoping this will give the game more lasting appeal, not to mention some ‘virality’.
Earlier this week, I added some variations to the procedural terrain in Dragon Attack.
Previously, the landscape was generated one segment at a time, forming a “chain” of rotated sprites. Each segment would have the same slope as the previous one, plus or minus a random number. To avoid going off the screen, the random number would be biased downwards near the top, and upwards near the bottom. This system worked great, but it made it pretty hard to implement variety in the terrain. For example, with just the previous height and slope as your “state”, how would you generate a mountain range?