Much has been said already on the iPad, but I thought I’d chime in. I’ll try to keep everything I say very clearly from a developer’s perspective. I’m excited to get one for my own use, but won’t go into the details here.

To understand exactly where I am coming from, here’s a little background. I have released apps for both the iPhone and the Mac, mostly games or entertainment apps. I am nearing completion of the biggest project of my life, Chopper 2, which will be released first on the iPhone/iPad, and later on the Mac.

So first, the thing I am most surprised and happy about; it’s dirt cheap. I, like many others was expecting a price point of $999, and to see the entry level model at $499 Is incredible. This is fantastic news, as it means more people will be able to afford it, which is more people who can play my games on it. At this early stage in the game it seems to me a very wise move, I just hope they are generating enough devices to satisfy the demand.

And yes, I think it will sell that well. Even in the very short time since it’s release, it has become clear that the hardcore geeks don’t tend to like it, while the general public will be lining up the day before. Exactly the way it should be. Like it or not, geeks do not make up the majority of the population. This is a device for the masses, as much if not more so than the iPhone. And for a game developer, this is a very very good thing.

This won’t be like the App Store gold rush though. When the App Store launched there were already millions of devices ready to rush in and snap up one of the couple of thousand apps available on launch day.

This time, there will be zero devices, and over 140,000 apps that already run. People will still look for iPad specific apps to run on their devices, but it will be a slowly rising level of sales. Sure Apple might sell a million devices on the first day, but it still pales in comparison with the App Store launch. App price expectations are also far lower now, and thousands of developers know how to code for the device, and have iPhone apps ready to port over with a day in Photoshop and a few clicks.

On a more technical level, the up scaling of iPhone apps doesn’t look very good. It simply takes every pixel you’d see on an iPhone, and makes it occupy 4 pixels on the iPad. No interpolation, no cleverness in it’s scaling. This is completely understandable, but means that demand for native/universal ports will be very high. I find it impossible to ignore a flood of emails requesting something, so know already that I will be doing an iPad version of the original version of Chopper.

So it is my belief that developers everywhere will be forced to upgrade their apps. Perhaps not initially, but as the iPad user base grows, it will be hard to ignore. And Apple have made it very clear that their preference is for a ‘Universal’ app – one that runs natively on both types of device. This has a couple of repercussions for developers (and customers).

Firstly, iPhone apps are going to get larger. With the larger display of the iPad, developers need higher resolution graphics to occupy all the pixels. They can’t just double the size of everything though, as that would look bad (and run slow) on the iPhone. So they need to provide two versions of most resources in their app. One the standard iPhone size, and one twice as big (4x the pixels, 4x the MB) as the iPhone version.

If the majority of an app’s size is imagery (which is often the case), this could mean the app is now up to 5x the size of the pure iPhone version. Actual sizes will be a bit less, but even 2x an 8MB app now means your app can’t be downloaded over 3G. And if a customer doesn’t own an iPad, it’s a lot of wasted bandwidth.

Secondly, as a developer, how am I getting paid for this extra effort, porting to the iPad? Some kind of in app purchase thing could theoretically be set up, but customers aren’t going to like that. I don’t really see that as an option. So it’s potentially a lot of work, that we pretty much have to do, for no extra revenue.

Personally, not getting paid for it may not be an issue. I fully expected Chopper 2 to run on a tablet, and have been planning for it since I started last year. With Chopper 1, I may just make the buttons smaller and call it an iPad version. Not sure yet, but perhaps it’s not a big deal.

But, I can definitely see how it could be a big deal for others. With a little foresight, 3D games are easy to port, but some applications are going to require some serious redesigns and graphical overhauls. And all this for zero devices on day one, and zero extra revenue? I’m not sure everyone will be jumping at the opportunity.

But overall, it’s awesome, I’m stoked. This is a device that will be sticking around for a long while yet, and I feel privileged to be able to offer my software on it.

I’ve been asked a little about my thoughts on marketing in the App Store lately. Back in the early days I felt qualified to say a lot, and did, but not so much anymore. However, I am very aware of just how difficult it is to get any kind of traction these days.

Word of mouth is king on the app store, but how do you get enough people using your app to start with so your good app can turn into a recommendation dirty snowball?

There is one important thing I feel developers can do but often fail at. So I’ll share this little tidbit of opinion, you can take it for what it’s worth.

Quite simply, it is: Do all your marketing at once, the very best you can.

That might seem obvious, or might not, I’m not really sure. But I often see developers launch an app with not a lot of fanfare, then when it doesn’t do very well, they try every different marketing method under the sun, one by one.

This is bad.

People are far more likely to notice a launch with an explosion of press than one with a puff here and there, and the press itself is more likely to notice the explosion too.

Basically it’s like a game of Crash Lander where instead of landing, you have to get off the moon. Earth is a far better place anyway. But on your earlier journey to the moon, Bubbles kept accidentally strapping the wrong tanks of gas to the side of the rocket, so now you have a dozen tanks of rocket fuel lying around, but you don’t know how full they are.

Do you:
A) Try them all one after the other, to see which one runs long enough to escape the moon’s gravitational field, or
B) Strap em all on and light em at once.

It’s simple physics. Do everything you can to get your app noticed on day one. If your launch fails, you’re going to have a hard time finding an alternate escape plan.

I know I’m going to get hate mail for this one… but here goes.

Recently I’ve been thinking a lot about user interfaces. I became enraged by the terrible user interface of Daz Studio, and then had the pleasure to use Motion. I have generally been using a large number of applications lately, and am currently creating my own fairly complex level editor for Chopper 2.

I could write many blog posts about all the different lessons I have been learning recently, but one in particular stands out.

Web apps suck. I’m talking about the web interfaces to the google suite, the photo editors, the facebook website. Apps that run in web browsers, any app that requires an internet connection to function at all, and does most of its work on a server somewhere.

Of course web apps have their uses. I don’t think they should all just go away, it’s nice to have a web app when nothing else is available. But what I’m saying here, is that compared to a native application, web apps are very much worse, for many reasons.

In the most simplistic sense; you need an internet connection, so your ability to access it is unreliable, you get presented with foreign looking – and behaving – buttons and sliders, and the service could go up in price, or simply disappear on you at any point.

But even if that is OK to you, and you like living on the edge, there is still the yucky user experience due to client-server communication. This is what I’m focusing on here.

The latency between action and response in web apps can be horrible, and this fundamentally comes down to the latency between the client and the server. A problem that I can’t see any solution to in the next decade or two.

Currently, the internet can be a little slow at times. It doesn’t matter if it’s due to server overload, bad local wifi or network, slow or misconfigured databases or whatever… there are many, many reasons why a ping to an app server might take a while, and it always seems to take ‘a while’.

Clicking a button in a local/native application, doing a minor computation, returning and displaying the results takes no time. I mean you simply cannot perceive the time it takes for the button to flash, simple data to get computed, and the result to be displayed. It’s stupidly fast.

Clicking on any button in any web app could take any amount of time. Usually it’s fast-ish. Sometimes it even appears to be as fast as a local app. But it’s not, and sometimes it is far worse.

So every web app, no matter how much it tries to pretend to be a native app, is reliant on the connection to its server, and hence can’t rely on some data being available. If you change some state, you can’t guarantee the state change was valid until the server responds. If you scroll down a list, you can’t guarantee that the new items being revealed will be available, or even still exist.

Most of the time it kind of works, kind of a bit slow, but OK. Every now and then someone turns a microwave on, and you wait. Every now and then someone changes a standard or a server config file, or you upgrade your browser, or the database overloads, and it all goes to shit. You might even lose all your data, despite your everything-in-triplicate local backups of your own machine’s data.

This is Bad. It will always be bad. As technology improves, the technology that uses it also improves. And web based apps are a step behind. Web apps will always have higher latency, more interface issues and a less ‘native’ experience. They will always be a worse user experience than native apps, with less user control.

So why make web apps? Because it is easier. Because a developer made a website, and suddenly it turned into a web app. Because a developer wanted to make something simple for Windows and Mac and iPhone and Linux and couldn’t afford to do it properly. Because a developer intends to inject advertising into the experience at a later date.

Most web apps don’t even have a revenue model. Those ones are figuring out how to capture people so they can spam them or sell their details later.

Web apps suck. They are a poor substitute for a native app, and will continue to be so, for many reasons, for many years to come.

I like to mix things up a little by writing little tutorials or sharing tidbits of information in-between my complaints and rants. This is one of those side quests, explaining how to easily add drop shadows or glows to the text that the Texture2D class renders.

If you don’t know what the Texture2D class is, various incarnations of it have been included in many of the iPhone OpenGL sample code projects from Apple. It was a very very useful resource giving developers a black box with a simple interface for loading and displaying images and text in OpenGL ES on the iPhone.

Currently however, this class does not appear to be available in any of Apple’s example source. Cocos2d still uses it, so you can find one example here: Texture2D.m Texture2D.h. I will base the modifications on this version.

Texture2D has two initWithString methods, one that takes a font, the other that takes a name and size. I’m just going to add two more that also take a shadow offset, blur and color.

@interface Texture2D (Text)
- (id) initWithString:(NSString*)string dimensions:(CGSize)dimensions alignment:(UITextAlignment)alignment fontName:(NSString*)name fontSize:(CGFloat)size;
- (id) initWithString:(NSString*)string dimensions:(CGSize)dimensions alignment:(UITextAlignment)alignment fontName:(NSString*)name fontSize:(CGFloat)size
    shadowOffset:(CGSize)size
    shadowBlur:(float)blur
    shadowColor:(float[])shadowColor;
- (id) initWithString:(NSString*)string dimensions:(CGSize)dimensions alignment:(UITextAlignment)alignment font:(UIFont*)font;
- (id) initWithString:(NSString*)string dimensions:(CGSize)dimensions alignment:(UITextAlignment)alignment font:(UIFont*)font
    shadowOffset:(CGSize)shadowSize
    shadowBlur:(float)shadowBlur
    shadowColor:(float[])shadowColor;
@end

Of course you can make the API whatever you like, pass colors however you like or whatever. All of the methods will eventually end up calling the last method there, taking a UIFont and shadow parameters. The others are just for convenience.

Now for the guts of the thing.

The first thing you need to do is switch from using a grayscale A8 texture and context (which lets be honest was a not particularly useful pain in the ass anyway) to an RGBA8888 texture. This gives you full control of the shadow color, as well as making blending easier when you come to use it later.

Replace the 4 lines that create the context with:

    colorSpace = CGColorSpaceCreateDeviceRGB();
    data = calloc(1, width * height * 4);
    context = CGBitmapContextCreate(data, width, height, 8, width * 4, colorSpace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big);
    CGColorSpaceRelease(colorSpace);

Also switch to using kTexture2DPixelFormat_RGBA8888 instead of kTexture2DPixelFormat_A8 in the call to initWithData

You should probably also change the line where it sets the fill color. Change the call

    CGContextSetGrayFillColor(context, 1.0, 1.0);

to:

    CGContextSetRGBFillColor(context, 1.0, 1.0, 1.0,1.0);

Note that this actually now allows you to set the color of the text. Where previously you would set the OpenGL color before rendering, you could now do it in this line, allowing a different shadow/glow color than the text color. It would be simple to pass the values in to this function and replace the 1.0s here if you ever wanted other than white text.

Moving right along, we get to the majic function call. CGContextSetShadowWithColor.

    if(shadowColor)
    {
        CGColorRef color = CGColorCreate(CGColorSpaceCreateDeviceRGB(), shadowColor);
        CGContextSetShadowWithColor (
           context,
           shadowSize,
           shadowBlur,
           color
        );
        CGColorRelease(color);
    }

I use shadowColor set to nil as the off switch for shadows, so it simply checks to see if we have a color, and if so sets the shadow properties on the CGContext.

And thats it! As I said before, make sure you set the pixelFormat in the call to initWithData to kTexture2DPixelFormat_RGBA8888 and change your blend modes when you render the text to something normal like glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

And create a texture with a shadow with something like:

    float shadowColor[4] = {0.0,0.0,0.0,1.0};
    text = [[Texture2D alloc] initWithString:@"Chopper 2 is gonna be freekin awesome!"
            dimensions:CGSizeMake(256, 128)
            alignment:UITextAlignmentLeft
            font:[UIFont fontWithName:@"Helvetica" size:18.0f]
            shadowOffset:CGSizeMake(2.0,-2.0)
            shadowBlur:2.0
            shadowColor:shadowColor];

Hope this is useful. I am not really handling the addition of extra padding to allow for large offsets or blurs, so watch out for clipping. It should be easy enough to deal with however. In the example below I actually offset the text on the left by the blur radius. This is a bit of a hack that doesn’t really solve the issue. An all encompassing solution is beyond what I wanted to do here, but in general, if you have clipping issues, play with that CGRect in the string’s drawInRect call.

Here is the new function in it’s entirety:

- (id) initWithString:(NSString*)string dimensions:(CGSize)dimensions alignment:(UITextAlignment)alignment font:(UIFont*)font
    shadowOffset:(CGSize)shadowSize
    shadowBlur:(float)shadowBlur
    shadowColor:(float[])shadowColor
{
    NSUInteger                width,
                            height,
                            i;
    CGContextRef            context;
    void*                    data;
    CGColorSpaceRef            colorSpace;

    if(font == nil) {
        NSLog(@"Invalid font");
        [self release];
        return nil;
    }

    width = dimensions.width;
    if((width != 1) && (width & (width - 1))) {
        i = 1;
        while(i < width)
        i *= 2;
        width = i;
    }
    height = dimensions.height;
    if((height != 1) && (height & (height - 1))) {
        i = 1;
        while(i < height)
        i *= 2;
        height = i;
    }

    colorSpace = CGColorSpaceCreateDeviceRGB();
    data = calloc(1, width * height * 4);
    context = CGBitmapContextCreate(data, width, height, 8, width * 4, colorSpace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big);
    CGColorSpaceRelease(colorSpace);
    if(context == NULL) {
        NSLog(@"Failed creating CGBitmapContext", NULL);
        free(data);
        [self release];
        return nil;
    }

    CGContextSetRGBFillColor(context, 1.0, 1.0, 1.0,1.0);
    CGContextTranslateCTM(context, 0.0, height);
    CGContextScaleCTM(context, 1.0, -1.0);
    if(shadowColor)
    {
        CGColorRef color = CGColorCreate(CGColorSpaceCreateDeviceRGB(), shadowColor);
        CGContextSetShadowWithColor (
           context,
           shadowSize,
           shadowBlur,
           color
        );
        CGColorRelease(color);
    }
    UIGraphicsPushContext(context);
        [string drawInRect:CGRectMake(shadowBlur, 0, dimensions.width, dimensions.height) withFont:font lineBreakMode:UILineBreakModeWordWrap alignment:alignment];
    UIGraphicsPopContext();

    self = [self initWithData:data pixelFormat:kTexture2DPixelFormat_RGBA8888 pixelsWide:width pixelsHigh:height contentSize:dimensions];

    CGContextRelease(context);
    free(data);

    return self;
}

With the recent public release of Snow Leopard, I have quickly found out that one of my creations – iSight Screensavers – no longer works at all.

As a result I’ve been asking myself a few questions, trying to figure out how I feel about the situation I’ve been put in. So I wrote the questions down, because that seems to be a good way to make me write about things.

Should Apple have broken every installed third party screensaver with the release of Snow Leopard?

Short answer: No.
Medium answer: I can see an excuse, but damn it sucks.
Long answer:

Here is a little background. With Snow Leopard, one of the key ‘features’ is the 64-bit transition. Apple OS developers would have been under a lot of pressure to make all of the system applications 64-bit. ‘System Preferences’ is no exception, and this is the application that allows users to configure screensavers. The screensaver configuration panel pretty much has to run in a 64-bit process if the System Preferences application is to be a 64-bit process, and the way this is all structured means that without a huge overhaul, all screensavers must be able to run in 64-bit mode.

And this is the problem. Nearly all third party screensavers will currently only run in 32-bit mode. Developers have been sitting in 32-bit mode for years, screensavers have always run in that mode, and there has been no reason or requirement for anyone to make most apps run in 64-bit mode. So for most users who upgrade to Snow Leopard, most of their third party screensavers will no longer function.

Frankly, this is a crap user experience. Apple are thinking forward, have forced developers to become backward, and in the process have created a bad user experience for anyone who had a screensaver installed, and required most screensaver developers to create and distribute a new version of their screensaver for Snow Leopard, or be blamed for the result.

I don’t know enough about what happens behind the scenes in the OS X code base, or in Apple politics to know if there is a fan-freekin-tastic reason for breaking all the screensavers in Snow Leopard. I can only hope there is, because from the outside looking in, it shouldn’t have happened.

Should Apple force developers to migrate to new features?

Short answer: Yes
Medium answer: In the name of progress, old applications may stop working over time, as long as ample notification is given to developers
Long Answer:

I’m all for progress. Keeping old things running with new technologies is a difficult task for anyone. However if any new software/hardware update ever makes an old document or application unusable, it is a bad thing, and it had better be for a good cause, and really must offer a switchover period for everyone.

Normally there isn’t actually an issue here, Apple usually run a pretty tight ship with feature regression in OS releases. Developers can target their own range of OS releases, they get warnings when certain things will get deprecated and everything is fine.

But in this situation, with any screensaver we have gone from compiles and runs fine, to does not work at all, in a single OS release.

Again, this only really applies to screensavers, and as you might imagine I am growing convinced that Apple don’t actually give a shit about screensavers, but here is the point: Apple wronged every Mac OS X screensaver developer. They instantaneously made all screensavers fail within a single point release. This is bad.

Is Apple obliged to make sure that every conceivable feature achievable in previous operating systems is also available in new operating systems?

Short answer: No
Medium Answer: They really should try really hard to make sure anything available in previous OS releases is also available in new ones
Long answer:

Again, in normal situations, Apple does a good job here. It is pretty rare that a new anything means that anyone can’t do something they did before. However it does happen.

In this case, with the 64-bit requirement, all screensavers must now only use 64-bit APIs. Quicktime is not usable directly, but must now be indirectly accessed via QTKit. But QTKit isn’t complete. There are many many things that the old 32-bit Quicktime framework could do that 64-bit APIs cannot. So any screensaver that used functionality available only in the Quicktime framework is screwed.

So I’m whining about stuff I can’t do anymore… boohoo…  But this is real. Hundreds of people have given me money for this screensaver, thousands more have pirated it. All of these people will now have to download a new version with no movie playback because it is not possible to achieve this with Snow Leopard.

Apple isn’t obligated to do anything here really, but it looks a bit bad. I won’t be defending Apple here, ‘Apple removed this functionality in Snow Leopard’ will be my response.

Conclusion

iSight Screensavers is now running in Snow Leopard, and I will distribute it as a Snow Leopard only separate screensaver next to the file that runs on 10.4 and 10.5. It took 3 full days to port, and I have had to remove the option for movie sources as Apple removed this functionality in Snow Leopard.

I don’t usually do video tutorials, or any tutorials at all really. But over the past few years I have experimented with a bunch of different methods for creating seamless tiling textures for use in computer graphics.

Many of them haven’t really produced good results, or have been fairly labor intensive. So when I finally developed a method that I felt worked really well, I always intended to share it. So here it is.

I use photoshop in the tutorial, but it should apply to any image editing software. If I subliminally stole this idea from someone then sorry! I’m pretty sure I came up with this myself though. It does seem kind of obvious too, so I wouldn’t be surprised if many other people already use this technique, but it took me a few years to figure out, so chances are it can help someone.

Hope it’s useful!

I’m a New Zealand based iPhone developer. I make games, for iPhones. So when a new model named the 3GS that was 2-3x faster and had a bunch of extra features useful to game development was announced at the WWDC keynote, I was really excited.

It’s now just over a month since that announcement. It’s 3 weeks since the iPhone 3GS was first made available to customers. A few people have asked ‘Did you get one to develop with early?’. The answer is no. Though that would have been a great way to get some new features in my games for people to use on their new iPhones, I still don’t have one.

Why not?

Well firstly, Apple don’t allow all developers early access to new hardware. A few lucky ones might get access, but most don’t. Fair enough I guess, Apple don’t want to leak new hardware details before they are announced.

Next, the iPhone first came out in the US on the 19th of June. Had Apple released it during WWDC when most of the developers from all over the world were in the US, we all could have had a chance to get one, but it was 5 days late.

Then it was announced to come out in NZ on July 10th. 3 Weeks after a million people had iPhones and were checking them out, I had a chance to test my games on one.

At this point the story changes. A day or two doesn’t matter when you’ve been waiting 3 weeks, but minutes do. Lies and confusion do.

On Thursday the 9th, according to Vodafone, the only way to get a 3GS without getting another plan was to buy one online on the 10th. Which meant I could get one delivered on the 11th.

That day I got confirmation from the @vodafonenz twitter user that MagnumMac would NOT be selling the new iPhone 3GS outright in the store.

On Friday the 10th, due to my distrust in Vodafone, I called MagnumMac. Sure enough, they were selling the new iPhone 3GS outright in the store.

So I went down to the store, I gave them my life details, and then got told that the sales guy would call to register the phone at some point in the next hour or two. So I could go away and come back when he could be bothered calling them.

And I still don’t have one.

Maybe I sound like a whiney kid who wants his new toys now! But really I would just like to get a chance to test and use new hardware at least at the same time as everyone else. And when I do finally get a chance to get the hardware it would be nice not to be treated like a criminal planning to ship 100 unlocked iPhones overseas. It would be nice if Vodafone made a bit of effort to promote the new phone, gave people a chance to queue somewhere, didn’t make things more difficult for current customers. It would be nice if MagnumMac staff weren’t so lazy and argumentative, and didn’t treat their customers like dirty retards.

I hate dealing with Vodafone, I hate dealing with MagnumMac. From the sounds of it At&T is just as bad in the US. The sooner Apple open retail stores with a cell tower on every corner the better.

UPDATE: The guy called me back, I have my new phone. It’s shiny. I take it all back, I love you all.

I have heard that copying any part of your code and pasting it somewhere else in your code is bad. The argument usually goes along the lines of ‘You needed it twice, so you should make a function’. OK, I’m thinking that maybe seems kind of reasonable, but I have to ask. WHY? ‘Because then when you need to make a change to that functionality, you can make it in the function, instead of two places in your code.’

OK so if both callers of that code need the same change, I can change it only once, instead of twice. Great! So making a whole extra function, making it callable from both places, passing in all the crap it needs from both places means that on the off chance that both of those use cases change in exactly the same way, I need only change the code in one place?

I don’t think so. I’ll change two places. In fact more than likely I’ll change one place. Or maybe I’ll change one place to do something a bit different, and then change the other place to do something completely different. And, I can do so and not worry about affecting anything else.

Screw DRY. I say repeat yourself, and then repeat yourself again.

Way back in 1848 (give or take 160 years), gold was discovered on a large estate in Cupertino, California. This estate was owned by one Mr Appleton.

Mr Appleton decided to mine the land in a very unique way. He invited miners from all over the world to work a claim for a mere $99 a year. In exchange for this cheap entry fee, the miners could not sell the gold themselves, but instead handed it over to Mr Appleton. Mr Appleton would then deal with the shipping and selling of all the gold, and give the miners 70% of all profits.

This deal was fantastic, and the estate turned out to be very, very rich in gold, so miners flocked in faster than Mr Appleton could collect the $99 fees. Everyone who had even seen a pick axe in a store was now a miner and a new claim was staked every ten minutes, twenty four hours a day for the entire first year.

But it wasn’t just individual miners working the estate, it was also noticed by the bigger, more established mining companies like ‘Mechanical Arts’ and ‘BottleCap’. These larger firms began to use their huge quantities of geologists and miners to find the best claims and quickly suck the gold out. Unlike normal mining operations however, their distribution mechanisms and relationships with the merchants were of little use here. Individual miners could work rich claims right next to these big companies on a utopian level playing field, the likes of which had never before been seen.

It wasn’t all plain sailing, however. Mr Appleton had some curious whims when it came to the quality of the gold he would accept. On one particular occasion Mr Appleton quietly changed his standards, and one sneaky snake oil sales man pounced on the opportunity. The salesman employed a miner to mine dirt instead of gold, and Mr Appleton just started letting it though. The merchants were momentarily confused by this new ‘gold’ so at first paid just as highly for it. After a while, though, they realized its worth, and though any nuggets shaped remotely like human genitalia or colored similar to Mr Appleton’s own prize nugget were rejected, dirt was let through where it accumulated in huge unwanted piles around Mr Appleton’s store houses.

Mr Appleton also had some rather unusual communication policies with the miners. When Mr Appleton forgot to pay the miners or was still pondering whether to accept the nugget that looked a little like a nipple if you tilted your head to the side and squinted just right, he could be contacted only by telegram. The problem was that all responses were typed by one of a dozen monkeys trained to give one pre-formatted response. On one occasion over a thousand miners cornered a representative of Mr Appleton on a stage where they attempted to ask questions, but the representative sprinted off the stage and escaped behind the curtains.

There was still money to be made however, and over time many miners became very wealthy from Mr Appleton’s estate. Though the easy pickings were gone, there was always a handful of miners pulling thousands of dollars worth of gold a day from their claims. Despite whimsical and sometimes completely non-sensical management, the gold rush on Mr Appleton’s estate changed the mining industry forever.