Twistago AI, part 3: Hard
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.
« Newer 1 2 3 4 5 6 7 8 Older »
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?
Jekyll is a great tool for creating (mostly) static websites; in fact this very site is built upon it. But it doesn’t come with built-in support for using multiple languages. This is a feature I needed for the website of Mystery Game No. 1, which will be released in German and English. I had to invent how to do it, because existing approaches didn’t quite fit the bill.
Princesses, snakes, and bears, oh my! In the form of Princess Maria, or some other form, make your way through 10 levels to save your fiancé, Plumber Pete, from the claws of an evil monster! Taking inspiration from The Talos Principle, Portal, Sokoban and a certain classic platformer, Morphing Maria is a top-down puzzle game in which you change shape to accomplish your goals. Each shape brings unique abilities that help you reach the exit.
With Mystery Game No. 1 in private beta, while I’m waiting for feedback, I’ve had all week to dedicate to Dragon Attack. A lot remains to be done, especially in the tweaking and balancing department, but there has been a lot of progress.
Yesterday I worked on the control scheme for Dragon Attack. In its original version, Glauron, the mechanics are very simple:
In the past few years, I’ve done most of my game development in Java. It didn’t use to be that way. Before Android and libGDX came along, when C++11 was still C++0x, I used C++ almost exclusively. And recently, because of some performance-critical bits in Mystery Game No. 1, I got to use C++ again. And I loved it!
At the start of this year, I set myself some goals for the first half of 2016. Today marks the half-way point of that period, so it’s a good time to check on how I’m doing on each of them. I’ll grade each goal on a scale of 0 to 1, which should ideally average out to 0.5 at this stage.
Update (14 September 2016): A month after I wrote this, RoboVM announced that they were winding down. I already had a (free) license, which is good until April 2017, but if you need a new one, you’re out of luck.
Update (14 September 2016): A month after I wrote this, RoboVM announced that they were winding down. I already had a (free) license, which is good until April 2017, but if you need a new one, you’re out of luck.
Rocket Mail was the first game in which I’m tracking metrics, using Google Analytics. Adding Analytics support to your app is fairly straightforward, but using it well isn’t. I’ve learned a thing or two from Rocket Mail, so with Mystery Game No. 1, I’m taking a different approach, as documented in this post.
Any programmer worth their salt will have heard of the DRY principle: Don’t Repeat Yourself. The idea is that repetition is bad: it makes for more code to read through, and it makes code harder and more error-prone to maintain because you have to make the same change in multiple places.
It’s Fun Time Friday again! And a good thing too, because I’ve been busy with Mystery Game No. 1 all week, which I can’t blog about yet. So apart from the welcome break, the Friday farming prototype also gives me something to write about.
While Mystery Game No. 1 is making nice progress, in the spirit of “throw stuff at the wall, see what sticks”, I’ve decided to introduce what I call “Fun Time Fridays”. On Friday, assuming the rest of the week has gone according to plan, I get to work on whatever I like, as long as it’s feasible that a game or useful product will come out of it.
With work full steam ahead on Mystery Game No. 1, it’s easy to forget that I’ve got another baby to care about. Rocket Mail was launched two months ago, but of course the story doesn’t end at launch. In a sense, it only begins.