It wasn’t even a problem until I made a sub-class that needed to use one of its super-class’s properties. It didn’t think the property existed. I thought maybe the problem was that the property was only synthesized in the super-class, so I tried copying the “@synthesize” line into the sub-class’s implementation. It seemed to work at first, but it turns out it was just creating a new property. It didn’t get or set the same data that the super-class was referring to.

Of course, what I was missing is that the whole point of properties is not to make a place to store data. You can do plenty of data storage with simple instance variables in the “@interface” block like so:

@interface Class : SuperClass
{
ObjectClass *myData;
}

You use properties when you want to give outside objects access to data, and all properties do is automatically create method to get and set instance variables. So I could write an object like this:

@interface Class : SuperClass
{
ObjectClass *_myData;
}

- (id)myData;
- (void)setMyData:(ObjectClass *)myData;

Or I could get the same result by writing this:

@interface Class : SuperClass
{
ObjectClass *myData;
}

@property myData;

Now when you write “@synthesize myData;” in your implementation file, you should think of that as the same as defining two methods, “myData” and “setMyData”. In fact, if you don’t write a “@synthesize” line and just start typing “- (void)setM”, Xcode will want to finish it as “- (void)setMyData” because declaring the property in the interface sets us up to expect getter and setter methods in the implementation. You can even leave “@synthesize” out of it and define the methods by hand, if you want. That can be convenient if you need extra stuff to happen when outside objects get and set your properties. Which leads me to another thing that confused me. When you define a property, you’ve also got options like this:

@property (assign) myData;
@property (readOnly) myData;
@property (retain) myData;

What’s the difference? The difference is what kind of setter method you’re automatically defining. “(assign)” gives you straight up assignment. “(readOnly)” doesn’t let you set at all. “(retain)” does the extra magic to manage the memory for your property. This is where properties get really nice. You can make sure your object is getting retained and released at all the right times if you use “(retain)”. And you can be sure that when you assign your property with a brand new object, the old one will be disposed of correctly. When you deallocate, you don’t release this kind of property. Instead, you just assign it to nil. Your synthesized setter method will do the rest.

• If you own it, release it.
• If you don’t own it, don’t release it.
• Override dealloc in your classes to release the fields that you own.
• Never call dealloc directly.

Which are made simpler by these rules about when you own something.

• You own it if you alloc it.
• You own it if you copy it.
• You own it if you new it.

Easy. As soon as you write one of those three commands, ask yourself where you’re releasing the object in question. If you allocate something in your init method, you probably want to release it in your dealloc method. If you allocate it in a method and never use it again, you probably want to release it in the method. If you allocate it in one place and then need to pass it off somewhere else, you probably want to autorelease it, which is just like releasing except that it doesn’t happen right away. Autoreleasing is good for methods that return objects. Chances are that when your method returns an object, the object that called said method will have a way to retain the object on its own without your help. And if it doesn’t, it should. A lot of your convenience methods like NSArray’s arrayWithArray: provide you with autoreleased objects, which is nice. That’s why you don’t have to release them yourself.

Things get a bit more complicated when you throw properties into the mix, but I’ll leave that for another time.

The Pie Chart Combat System is one of the fundamental things I carried over from Dungeon Escape to Dungeonism. It was a crucial piece of value I was going to preserve in the new, simpler game, while most things around it changed. In some ways, it was the central aspect of Dungeonism.

That is, until I got rid of it, which I had to do because it was getting in the way of some other mechanics I had added in. Because one of my goals for Dungeonism was to make the player use the space a little more in his strategies, I came up with a new blocking system. Attacks would always get blocked when the defender was facing the attacker. Right away, this encourages you to always step around your victim before you hit them, which you’re not always close enough to do. (The defender also automatically turns to block if he rested that turn.) This sets up an interesting trade-off that gets too muddied when you’re also hoping not to get tripped up by pure chance. And along with some fatigue-based mechanics, it makes combat interesting enough that any benefit from the ambiguity of a random system is redundant. Sorry, pie chart.

cocos2d was originally written for Python, but it’s been ported to Objective-C, and it’s become a very popular way to make iOS games. It provides an intuitive way to create sprites, move them around, and recognize touches. It also makes it simple to create menus and to switch between scenes. In no time, I recreated everything I’d done from scratch (not much) and was ready to import some the images I had from the Dungeon Escape prototype. Gladly, I left behind grappling with graphics and user input, and I was able to really work on the game. Fantastic.

And Dungeonism doesn’t even use the physics engines Box2d (used by Angry Birds) or Chipmunk, which are integrated into cocos2d for iPhone. It’s no wonder there are so many games that use cocos2d.

Dungeonism

Blog went dark for a while. Hmmm… I guess I was concentrating too hard on my new project Dungeonism. It’s a dungeon crawling game for iPhone. I’ve been coding it since January, and I estimate it’s 50% done, but that might be optimistic. The gameplay is certainly 50% done, but after that, I have a lot of audio-visual polish to add. Right now, it’s a silent game with simple geometric artwork — which captures the classic gaming spirit the final game will have, but more refined.

Dungeonism began life last year as this semi-absurd concept: a 2-dimensional, turn-based take on the Elder Scrolls games. I guess it grew from my desire to continue to play Oblivion while I was in meetings at work. There should be an engrossing fantasy game that demands the same amount of your attention as Bejeweled. To this end, I spent a few months building an HTML/JavaScript prototype of a dungeon game, which you can mess around with if you want. Let’s call this iteration Dungeon Escape. You can play what I made here: http://lab.softwerewolf.com/dungeon/de.html

As you can see, Dungeon Escape has a more detailed (if crudely so) look to it, and that’s because it emphasized world exploration. It was going to take place in a vast world with settings and characters and stories and lots and lots of content that would’ve take many many hours of work to create.

The emphasis in Dungeonism is pure gameplay. You do unlock new dungeons in it. And you do develop your character. But the dungeons are created procedurally each time you play them. And you develop your character so you can play harder dungeons, traveling deeper into them, and encountering new monsters.

It’s a more casual approach, and it brings it closer to the original idea for creating a low-attention, still-immersive experience.

I decided to give Edge a spin, and I made this unfunny Eddie the Brick cartoon with it.

The current release is Preview 1, and it’s pretty rough. While working with it I ran into several bugs and missing features. When I first saved my project, it reset all my settings. I was stumped for a bit because I turned off the auto-keyframe function and didn’t realize there was also a function that was hiding all my static objects (because they hadn’t been automatically given keyframes). My project involved bits of text appearing and disappearing, and I couldn’t find a way to have objects only appear at certain times. I used opacity keyframes instead. Images can’t be scaled in the interface. Also, the full animation can’t be looped. None of these are big deals, and I’m sure Adobe will address them as development continues.

One thing that might be an issue occurred when I added a whole bunch of keyframes. Eddie is jittering for the whole animation, so I created a repeating pattern of him slightly, rapidly moving about. The last few pastes I did of the pattern made the program hang for several minutes. It probably also makes up the bulk of the 240k JavaScript file Edge created for the project.

All in all, it’s a cool start, and I look forward to a much-polished version of this becoming a standard part of my workflow.

Besides, someone has already gone through the pain for me: real estate websites. I won’t say exactly which site I went to because I’m pretty sure harvesting their data would be considered a terms of use violation. But let’s just say there’s a site out there (and there are several, actually) that serves up all kinds of basic, publicly available data about homes, and they make it easy to browse the entire Denver Metro Area from a single starting page. It couldn’t be more perfect for spidering and data-scraping.

This was my first time building a spider or scraping, but it didn’t take much searching around to find Scrapy, a Python framework for doing just this. It’s a little complicated to start, but they have a good tutorial, as well as a live command line environment that lets you test out code.

In the end, it worked beautifully. If you want the data I scraped, it’s here: Denver Metro Property Data

Now if I can just figure out how to call Google’s GPS-finding service more than 15,000 times a day…

Here is the source for the plugin, which is made up of three files — two JavaScript, one PHP. The PHP file splitter.php defines the plugin, some settings, and inserts JavaScript based on those settings into the header of the page. The JavaScript file splitter.js does the work of actually setting the cookie, modifying the page, and setting the Google Analytics custom variable.

As for trigger_yoast.js — unfortunately, I ended up coding Splitter to work specifically with Yoast’s Google Analytics plugin. This was a tricky issue for me to figure out because the custom variable has to be set after the Google Analytics scripts are included but before the pageview event is fired. With a Google Analytics plugin, Splitter’s JavaScript can’t run until after the plugin is initialized, but then the plugin has to wait for Splitter to set the variable until it can finish what it’s doing. Yoast’s plugin lets us do that by providing the “Where should the tracking code be placed” and “Custom Code” settings. If the first is set to “Insert manually”, then it’s up to me to trigger the pageview event, so I added a footer action in splitter.php to do that. Then I set the “Custom Code” to call the function in splitter.js — gaVariable() — that sets the custom variable.

I used this to explore whether a couple of the widgets I’ve got in the sidebar of Truth (plus lies) were worth their real estate. The first was the tag cloud. I decided that the goal of my tag cloud was to encourage visitors to explore the most common topics on my blog, so if it was successful, the tag cloud would be driving down the bounce rate.

In my Splitter settings, I created state A, which showed the tag cloud widget, and state B, where it was hidden. The element is defined by a CSS selector. I defined my cookie name as ‘tagcloud’ and my two states as ‘yes’ and ‘no’. With this information, I created two custom segments in Google Analytics that matched for the custom variable name and values, which are the same as in the cookie. Then I applied my segments and checked out the Bounce Rate report for the home page of my blog. (The home page is the only page that had the tag cloud.) Here were my results:

The total bounce rates were: 60.53% total, 68.18% with the tag cloud, and 53.33% with no tag cloud. So, a definite win for removing the tag cloud, right? Not necessarily. Here’s where I’m a total beginner at A/B testing. These results were for just 65 total pageviews — 40 with the tag cloud and 24 without. (I don’t know where the 65th one went.) This leads me into the biggest A/B testing trap, statistical significance. Crazy things can happen by chance, so it’s important to be rigorous about making sure your test results actually say something useful about your design.

The home page of Truth (plus lies) doesn’t get too many hits. Most of the traffic goes to single post pages, so I decided to end my split test without a strong conclusion. I did go ahead and remove the tag cloud though. Not only did my aborted test show no advantage, but some click tracking I was doing at the same time showed that no one ever clicked the tag cloud.

Before doing my second test, I improved Splitter by automatically turning my A/B tests into A/B/A tests. That is, when you create to states to test, the plugin will create a third “control” state that is a copy of the A state. The control state is tracked separately, so in Google Analytics, you’ve got three segments to look at. But now you know that two of these segments should be producing pretty much the same results and that any difference between them is pure chance. Which is helpful when you’re trying to decide if a difference between states A and B is significant.

Armed with this new feature, I set up a test that either shows or hides the “About Me” widget in Truth (plus lies)‘s sidebar. Actually, the test’s still going, and it’s been going for over a month. Here are the current results in Google Analytics:

Still ambiguous! There’s a slight advantage for the “With” states. But for bounce rate, the difference between “With About Box” and “With About Box (Control)” is bigger than the difference between the control state and “No About Box”. A little clearer are the numbers for “Pages/Visit” and “Avg. Time on Site”. Both show “With” and “Control” close together and doing better than “No About Box”.

But only slightly. More than anything, my tests show me that the presence of both these widgets doesn’t make much difference to the users.