Fear and Loathing on the Learning Curve: Observations on Life, Tech and Web Design from a Slightly Misanthropic Mind

The Race to the Bottom

Ustwo’s Monument Valley is get­ting a hard time in the App Store right now because its cre­at­ors dared to release addi­tional con­tent for the $4 game as a $2 in-app pur­chase. Disgruntled play­ers are leav­ing 1-star reviews to protest the paid-for extra levels, des­pite appar­ently enjoy­ing the game a lot, like “Jared” in this ridicu­lous example from yes­ter­day. Having not pre­vi­ously bothered to review the game they liked so much, these people decide an appro­pri­ate form of protest is to leave an angry neg­at­ive review to drag the game’s score down. They’re not review­ing the game, they’re review­ing the idea of a chunk of new con­tent they’ve decided not to buy because it costs money.

Do people have any idea how much weight these review scores have? No. Indie developers are made or broken by this sort of thing, and using reviews as a weapon in this way is ridicu­lous. It hurts the people that need it most, and it’s a great way to ensure that the App Store becomes a place where you can’t get great indie games (that you enjoyed, until just now!) because those developers will go broke or go else­where. The App Store is chock full of dross, and it boils my piss to see suc­cess­ful break­out hits like Monument Valley be dragged under because they dared attempt to charge a fair price for their work.

People have no idea how much effort goes into cre­at­ive work. They also appar­ently don’t under­stand com­merce. When you buy some­thing, unless stated oth­er­wise you’re hand­ing over money for a product as it stands right now. You pay money for a sand­wich; you pay money for a book; you don’t expect any free food or book con­tent after the point of pur­chase, right? Of course not. When Phil Fish announced he wasn’t going to con­tinue devel­op­ing Fez 2, he was attacked by people who con­sidered that their pay­ing for the ori­ginal Fez con­sti­tuted some sort of con­trac­tual oblig­a­tion to Phil Fish to keep work­ing on new Fez games. That they had “fun­ded the devel­op­ment” (actual quote) of Fez 2 with their pur­chase of Fez. Uh, nope. That’s not how it works. Indie developers typ­ic­ally get into all sorts of debt while ded­ic­at­ing their time to mak­ing games, and if they’re lucky they can pay that back if they even­tu­ally sell. Phil Fish wasn’t sit­ting on a pile of cash idly con­sid­er­ing whether to make another game with it. Watch Indie Game: The Movie (which you’ll have to pay money for, sorry) to see this in action with a bunch of other developers.

We are appar­ently rap­idly approach­ing a world where own­ers of $600 smart­phones not only balk at pay­ing more than $4 for a game (this is a well-established joke) but expect that $4 game to come with free addi­tional con­tent for life. The author of the review linked above refers to Candy Crush (core game free with boost­ers avail­able via IAP), which is pro­duced by a massive stu­dio, and only massive stu­dios can afford to give away their con­tent in this way because other games in their port­fo­lios can cover their costs. Indie devs can’t do that. And yet people con­tinue to treat all developers as equal and any­one try­ing to recoup more than a pit­tance in the pri­cing of their work is pilloried.

The App Store pri­cing tiers don’t help this. Anything above $4 seen as being wildly sus­pi­cious; these are tiers gen­er­ally reserved for spe­cial­ist applic­a­tions. Developers tar­get­ing the mass mar­ket are incentiv­ised to charge lower and lower prices for their products (and don’t for­get Apple takes a cut too), and for a lot of people the price of an app becomes the determ­in­ing factor in a purchase.

We have to make this bet­ter. Indie developers need to be able to charge a fair price for their work. Players need to get their enti­tle­ment issues under con­trol. The App Store review sys­tem needs to take account of this sort of weapon­isa­tion. And per­haps we all need to get used to a world where qual­ity might cost more than $4.

Notes on upgrad­ing to Django 1.6 and 1.7

Django 1.7 was offi­cially released this week, prompt­ing me to dig into my live Django pro­jects and see which were des­per­ately in need of upgrading.

Fear of get­ting myself into trouble with the new migra­tions sys­tem made me hold back on some pro­jects and upgrade them only as far as 1.6.7, but most pro­jects were bumped all the way to 1.7. Here are a few notes on com­mon changes you might have to make if you’re com­ing from older ver­sions of Django, par­tic­u­larly 1.3 and 1.4.

New migra­tions sys­tem
The most major change intro­duced in 1.7. If your pro­ject uses South migra­tions you’ll need to fol­low the instruc­tions here to gen­er­ate new ini­tial migra­tions for each app in your pro­ject. This seemed to work fine on the pro­jects I upgraded to 1.7.

Adding ALLOWED_HOSTS
If you’re upgrad­ing from a ver­sion of Django prior to 1.5, you’ll need to add the ALLOWED_HOSTS vari­able to your set­tings file, or Django will raise a SuspiciousOperation excep­tion when you try to load your site.

New guni­corn init style
I was using an embar­rass­ingly old ver­sion of guni­corn on some pro­jects – 0.12.2, for example; the cur­rent ver­sion is 19.1.1 – and at some point the recom­men­ded init style changed from a man­age­ment com­mand (django-admin.py run_gunicorn or manage.py run_gunicorn) to a stan­dalone com­mand: gunicorn myproject.wsgi. This ref­er­ences the WSGI applic­a­tion defin­i­tion in your project’s wsgi.py cre­ated as part of the pro­ject gen­er­a­tion pro­cess. If your pro­ject was cre­ated prior to Django 1.4, you’ll need to add your own wsgi.py file. Docs here; gen­er­ated code from a sample pro­ject here – replace myproject with your pro­ject name.

You’ll need to change the init style in any pro­cess man­ager you might be using, such as Supervisor, and also in your Procfile if you’re using Heroku. E.g. from this:

web: django-admin.py collectstatic --noinput; django-admin.py run_gunicorn -b "0.0.0.0:$PORT" -w 4

To this:

web: django-admin.py collectstatic --noinput; gunicorn myproject.wsgi -b "0.0.0.0:$PORT" -w 4

Adding new style test run­ner
Your test run­ner now needs to be expli­citly declared in your pro­ject set­tings, so I found I needed to add the fol­low­ing set­ting to pre­vent a warn­ing mes­sage (source):

TEST_RUNNER = 'django.test.runner.DiscoverRunner'

Updating {% url %} tem­plate tag style
If you’re upgrad­ing from prior to 1.5, you’ll need to quote route names and view paths passed to the url tem­plate tag – e.g from {% url path.to.your.view %} to {% url ‘path.to.your.view’ %}.

Replacing direct_to_template with TemplateView
Earlier ver­sions of Django sup­por­ted the direct_to_template short­cut to quickly render a tem­plate without a view – this has now been removed in favour of the TemplateView Class-Based View. If you have any URL pat­terns that look like this:

url(r'^404/$', direct_to_template, {'template': '404.html'}),
url(r'^robots\.txt$', direct_to_template, {'template':'robots.txt', 'mimetype':'text/plain’}),

You should replace them with this:

url(r'^404/$', TemplateView.as_view(template_name="404.html”)),
url(r'^robots\.txt$', TemplateView.as_view(template_name='robots.txt', content_type='text/plain’)),

Virtualenvs los­ing their setuptools
During some lar­ger upgrade runs on my devel­op­ment box, pip would occa­sion­ally drop the ball and refuse to per­form any oper­a­tions, giv­ing the error ImportError: No module named pkg_resources. Reinstalling setuptools using the advice here sor­ted it.

Quickly upgrade all pack­ages in requirements.txt
Lastly, I found for most pro­jects I wanted to upgrade all the pack­ages lis­ted in requirements.txt (which includes pinned ver­sions) — but pip doesn’t yet have a one-stop com­mand for this. I found that some­thing like this usu­ally worked:

cat requirements.txt | grep -v '^-e' | awk 'BEGIN{FS="=="}{print $1}' | xargs echo pip install --upgrade

I’ve since dis­covered the exist­ence of pip-tools which has a com­mand that takes care of this for you.

You’ll prob­ably find a few other bits and pieces that need adjust­ment before your pro­ject will work per­fectly with Django 1.7, but hope­fully this cov­ers some of the more com­mon cases.

Posted September 7th, 2014

The Reckoning of the Finish

A Life Well Wasted – pos­sibly the most thought­ful videogame-related pod­cast ever – is back, and the new epis­ode is some­thing spe­cial. Robert Ashley talks to sev­eral indie game developers about their work, and one quote in par­tic­u­lar – from Greg Wohlwend, one of the developers of Gasketball – struck a chord with me, given what I wrote about fin­ish­ing things last week.

Continued →

Posted March 24th, 2013

Introducing Suncaster, and a few words on fin­ish­ing things

The winter months were get­ting to me recently as they so often do, so last week I released Suncaster, a little app that uses your loc­a­tion and the time you leave work to determ­ine when you’ll next be able to hit the streets before the sun sets (my favour­ite time of day).

Continued →

1

CSS3 Sprite Animations With Steps()… Almost

I’ve recently been pok­ing around with sprite anim­a­tion for a new ver­sion of this site (more on that later), and since I’m try­ing to show off my cutting-edge front-end chops I wondered if there was a way to accom­plish this anim­a­tion without using JavaScript. And there is! Sort of.

Continued →

Posted November 29th, 2012

Indie Game: The Movie

Yesterday one of my esteemed col­leagues aler­ted me to the recent release of Indie Game: The Movie, so last night I sat down with a friend to watch it. We were both abso­lutely blown away by it. It’s a beau­ti­fully shot doc­u­ment­ary fol­low­ing a few dif­fer­ent developers as they work on or reflect upon their titles – Jonathan Blow talks Braid, the guys from Team Meat hustle to fin­ish Super Meat Boy for its XBLA release, and Phil Fish drags Fez ever closer to its own (now at last arrived) release date.

Continued →

Posted June 14th, 2012

You can find a complete history of older posts in the Archive.