The unnamed RPG

Posted by

This post provides a bit of an overview of my plans for my as-yet unnamed RPG. One of the biggest lessons I learned with my previous game (which I talked a bit about here) is that players want to interact. The in-game chat was pretty much an afterthought in my previous game (in fact, it was the very last feature I added before going to "alpha"). Most of the work I did post-release was community-based features -- an alliance system, one-on-one and group private chats, and so on.

So I wanted to make sure my new game supported a vibrant community right from the beginning. Also, I was a little tired of the limitations of working with a phone, so I wanted something that ran on a PC. But more than that, I wanted something that was cross-platform (I personally use a Mac laptop and a Linux workstation, so it needed to run on those platforms as well as Windows, of course). Because I'm a masochist, I decided make the game browser-based.

The first iteration I was using a <canvas> directly and drawing 2D sprites. It worked pretty well, but performance was generally pretty horrible -- and that was with practically nothing on the screen! I actually got pretty far with that 2D engine, including multiple players, chat, animations and so on. Here's a video:

That video didn't have pathfinding, but that was also added before I decided that the performance just wasn't there. My plan was going to be to use webgl to speed up the 2D engine, but as I was coding, this happened

So I made it fully 3D with three.js as the backend renderer. In fact it's actually not that hard to get webgl up and running -- the hardest part, at least for me, was content. The initial "rewrite" was still talking to the same backend server, so it still supported all those wonderful multiplayer features, but I had an MD2 model (from Quake) as my main character, and some procedurally generated tree I found somewhere as decoration.

The most interesting thing about the rewrite is the terrain. I found this cool article on Gamasutra and implemented it as a GLSL shader in three.js.

Then I taught myself how to use blender to create some basic 3D objects and animations. All the content in the current gameplay video was made by me in blender. Yay!

So that's where we are today. I've have a few ideas for the basic premise behind the game and also some information on how the game has been "architectured" (I put it in quotes because it's much more organically developed than architectured...)

What's the deal with USB headphones?

Posted by

Why do these things exist? A while back, I bought a pair of Logitech H390 headphones. This is what they look like:

When I bought them, I didn't really spend a whole lot of time looking at the box, but the fact that the interface is USB is shown in that little info panel on the bottom-left. In retrospect, I probably should have spend more time reading that box because it turns out, USB is a horrible, weird interface for headphones and I can't for the life of me understand why they exist.

Cons of USB headphones

These are just the ones I ran into while using my headphones over the last year or so:

  • They only work in a couple of places. PC, sure. Maybe I could plug them into my Android phone with a USB-A to micro-USB adapter, but I never bothered to buy one in case it didn't work. A Ninentdo DS or practically anything else that's not a PC? Forget it!
  • Even when it works, because the headset shows up as a separate device, you can get yourself into weird situations where audio would continue routing to your main speakers and not the headphones. Both Windows (as of version 7, I haven't tried newer versions) and Linux have fairly clunky interfaces for choosing which output device to use. In most cases, with regular headphones, once you plug in all audio is automatically routed to the headphones.
  • Because the DAC happens inside the headphones, you can be pretty sure the quality of that hardward is nowhere near the quality of the hardware in your desktop computer.

Pros of USB headphones

¯\_(ツ)_/¯

Oh wait, I can think of one "pro". The Creative Tactic3D Rage headphones has illuminated ear cups. For some reason.

Connecting from your Android device to your host computer via adb

Posted by

Sometimes when I'm on the road, and using someone else's Wi-Fi (typically when I'm in a hotel), they will allow you to connect your phone and your laptop to the internet via their Wi-Fi. But, for security reasons, they typically won't allow your phone to connect to your computer over the Wi-Fi network. This make debugging certain applications quite difficult: I can't run a server on my laptop and have my phone connect to it.

But luckily, in recent versions of adb, a new command has been added: adb reverse. It's basically the opposite of adb forward, which lets you forward ports from the host to your device, adb reverse allows you to forward ports from your device to your host.

So let's say I have a server running on my host computer, listening on port 8080. I want my phone to connect to it, so I run:

$ adb reverse tcp:8080 tcp:8080

And then connect to 127.0.0.1:8080 on the phone and problem solved!

Like adb forward, the parameters correspond to server/destination ports. But in the case of adb reverse, the first parameter is the port on the device and the second is the port on the host you want to forward to.

A battery widget with support for monitoring your wearable battery level

Posted by

I released the first version of "Advanced Battery Monitor" towards the end of last year, to not much fanfare at all. I used it and a couple of my friends used it, and that's about it.

But since getting my hands on an Android Wear watch (Moto 360, to be precise), I added a new feature to my graph to also monitor the battery on the watch.

Here you can see my phone + watch battery level thoughout the day today:

The green line represents my phone's battery, the blue my watch's. I use both devices fairly heavily throughout the day, so I'll let you make of these graphs as you will.

The other feature I've added is the ability to export your battery data. The app only keeps battery data for up to a week, but you can export the whole data by tapping the widget to get into the "settings" and using the Export option.

The source code for the widget is available on github: https://github.com/codeka/advbatterygraph

And of course, the widget itself can be downloaded from the Play Store:

 

Playing around with a random level generator

Posted by

So, one of the things I've been toying with recently is the idea of a Diablo-style hack & slash. One of the most important aspects of the hack & slash is level generation. There's lots of ways you can generate levels and lots of different "looks" you can give your levels. I plan to explore a few different techniques over the next few weeks. My first attempt, which I've included below, gives a sort of cavernous look that I think would be good for boss levels:

The technique is quite simple, I "borrowed" the idea from this page. Basically, the algorithm runs as:

  1. Fill the board with random walls. Each square starts with a 45% chance of being filled.
  2. Each iteration, for each square, count the number of walls around that square. If there is more than 5, fill the wall in a new version of the map.
  3. Repeat step 2 until the map is "stable" (that is, until two iterations produce the same map).

In the example above, you just let it run normally, it'll do a few iterations, then complete the run in one go and pause for a few seconds so you can see the outcome. You can click "stop" then use the "reset" and "step" buttons to manually progress through the iterations.

There's a couple of problems with this, though. Firstly, it tends to make very open levels. I guess depending on the game, that may or may not be OK, but for our purposes, I think I'd like something a little more close-quarters. Another problem is that it produces overly "smooth" walls, that is, there are no sharp corners and no sharp points. Again, depending on your level design, that may or may not be OK, but I'd like to do something about it.

For the second problem, the solution is actually quite simple: just don't run the algorithm so many times. If we cap the number of iterations to, say, 10, then we end up with more jagged walls. But that introduces an extra problem: sometimes it will leave behind very tiny "islands" of walls, which the old alorithm would have smoothed away. That can be fixed by a "manual" cleanup afterward where we simply remove the small islands.

For the first problem, we modify the algorithm slightly:

   Map.prototype.iterate = function() {
      var newMap = new Map(this.width, this.height);
      newMap.clearMap();
      for (var x = 0; x < this.width; x++) {
        for (var y = 0; y < this.height; y++) {
          if (this.numWallsWithinSteps(x, y, 1) >= 5) {
            newMap.setCell(x, y, 1);
          } else if (this.stepNo < 6 && this.numWallsWithinSteps(x, y, 2) < 2) {
            newMap.setCell(x, y, 1);
          }
        }
      }
      newMap.stepNo = this.stepNo + 1;
      return newMap;
    };

The above algorithm can be seen in the map below:

As you can see, this version results in much more "cramped" level than the first version. You can download the full code for the final version here.

This is a pretty simple algorithm and produces nice levels for boss fights, but next time, we'll want to try a slightly more complicated algorithm for generating the room/corridor style levels that you come to expect.