legendary beauty like the moon

My short experiment in good neighborly conduct is over. For a few weeks, I was running my wireless LAN without encryption, but now AT&T has put a bandwidth cap on my connection.

It’s funny how many people will run non-SSL traffic over an unknown WLAN called AndroidAP without so much as a second thought. It’s trivial for anyone on that network to read your traffic, people! Also, watching netflix over what looks to you like a tethered phone is just a bit mean, don’t you think?

The title of this post is my new SSID 🙂 I figured Persian poetry was nicer than those passive aggressive “I can hear you through the wall” network names that are so en vogue, and more likely to make someone smile.

Atlantis TDD (4) Working with Legacy Code

After all this prep-work, it’s time to actually work on the game. Which game? I’m going to use Atlantis 1, the original game that started it all. The movement code in it is really gross, and the code only compiles under DOS, so the first order of business is to clean it up a bit. The result compiles under Linux without warnings, and even if nothing else comes out of this project of mine, at least there is now an Atlantis 1 code base you can just use.

This is classic legacy code: It’s not very modular at all, and there are absolutely no tests. Before I make any changes, I want to make sure that I won’t break anything, so I am going to put the movement code under testing. For this, I’m extracting the movement code into a process_movement function. Next, I’m going to make sure all code paths in that function are tested at least once.

static void test_movement(CuTest * tc)
  unit * u;
  region *r1, *r2;

  r1 = createregion(0, 0);
  r1->terrain = T_PLAIN;
  r2 = createregion(1, 0);
  r2->terrain = T_PLAIN;
  createregion(2, 0)->terrain = T_PLAIN;
  u = createunit(r1);
  strcpy(u->thisorder, "move east");
  CuAssertPtrEquals(tc, u, r2->units);

Since this test is only protecting the original Atlantis game against regressions, I can write it in terms of the Atlantis code base and its objects (and use r2->units directly, etc). As long as this test passes, I can be certain that regular unit movement works. This kind of protection gives enormous peace of mind to a programmer who is working with a code base that isn’t his own (or is son old he doesn’t remember writing it). A couple more tests around modifications in the Atlantis source needed to be written, you can find them in the atlantis_test.c source on github.

Next up, I’m going to slap together an interface to stitch the Atlantis 1 implementation into my interfaces! And maybe then I can write my movement logic?

Atlantis TDD (3) CMake is awesome

I started this project with a simple Makefile. Eventually, I’d gotten to 30+ source files, and the Makefiles were getting cumbersome to update. I mean, judge for yourself: How easy is this?

cmake_minimum_required(VERSION 2.4)
project (logic C)

include_directories (..)

set (MOCK_SRCS ../mock/region.c ../mock/unit.c
../mock/keyvalue.c ../mock/mock_svc.c) add_executable ( movement_test movement.c movement_test.c ../cutest/CuTest.c ${MOCK_SRCS} ) add_test(movement_test movement_test)

This is the rule to build the tests for my movement code and link them with the mock implementation of the game structures. It’s platform-agnostic, too: On Windows, I can use this to build Visual Studio project files. On Linux, cmake generates Makefiles for me that are far cleverer than any I ever wrote by hand.

This isn’t my first project to use CMake. I’ve looked at a lot of build systems over the years, and this is the one I’ve stuck with. There are still things that are hard to do in it, but they are the kind of things that are huge pains in every other build system, too. But the easy stuff, the 95% of the work, is actually easy.

This is the first time I’ve used CTest, though, which ships with CMake. You can add all your tests with the ADD_TEST command, and CMake will generate the input for CTest from that, so you can run all the different tests in your project with a single command.