World::Create()

AvatarProgramming ramblings with some vague emphasis on Games, Games Tools and Web.

What will happen to newspapers and journalists?

A couple of nights ago I went to see Simon Singh announce whether or not he will be appealing in the libel case that has been brought against him by the British Chiropractic Association. I went to the event to show my support for science against pseudo-science, but came away with a new found loathing for the British libel laws, which seem to be fundamentally flawed and heavily in favour of the corporation and the rich.

However, almost in passing, Nick Cohen mentioned something that - combined with a TechCrunch post I'd read that day - sparked a few neurons and I thought I'd jot it down.

Nick mentioned that newspapers are in decline; blogging is on the rise but that no one is making blogging pay and so how do the journalists continue to exist. ( I'm paraphrasing that pretty heavily, but I think that was the general idea. )

On the way home, my girlfriend and I were thrashing out ways in which it could work and I came up with this comparison.

Today, the newspapers work like this: a bunch of writers create content which are then aggregated by a selected few editors into a handful of publications which are then distributed daily or weekly. The writers are paid by the publication and the publication costs money and charges for advertising space. At the moment it just about works but revenues from sales are falling as more and more people get their content online. Online advertising on their websites in not enough to fund the whole process.

Now how about this scenario: A bunch of writers create content which they post on their individual blogs. This content is aggregated by an computer program based on criteria set by the reader ( e.g. Google Reader ). There are no longer a handful of publications but millions, one for each reader. The writers place adverts in their work, which is included into the RSS reader. As they are a single individual with minimal hosting costs, the revenue from the ads on their work is enough to pay themselves.

This is not a new suggestion, it the basis behind the whole blogging movement. So why are journalists like Nick Cohen unable to make a living from his writing? Note, I realise that Nick doesn't have any adverts on his site, but I believe the point is still valid. TV channels like ITV have existed for years and years entirely funded by adverts. In these days of targeted advertising like Adsense shouldn't this all be possible?



It seems to me that the problem is targeted advertising doesn't really work for high level content like this. As a scientific sceptic and someone who isn't interested in suing anyone for libel, what adverts do you think I would see when I'm reading a blog post about Simon Singh being sued for libel by the British Chiropractic Association? The image on the left is the result of a Google search for "Simon Singh Chiropractic libel".

I suppose that some people reading a blog post about this subject would be interested in finding a Chiropractor, but I would have thought there are better advertising subjects like, for example, books by Nick or other Guardian journalists.

When I started writing this post I was going to that what we need are advertising services where I can sign up for a specific demographic. e.g. C# coders, Games Developers, etc. and then I would get targeted adverts with a higher level focus, not just focus on a couple of key words in the post. However, I've no doubt that this actually exists somewhere, I've not looked. So what is lacking? Probably that the advertisers still aren't twigged to the whole online thing. The people who read a Nick Cohen blog, or a blog about Game Tools development should be the easiest people to advertise to in the world. You know exactly what to advertise to them. Well, in fact you probably don't, but you should know what not to advertise to them, and I'm pretty sure Chiropratic services is one of those things.

The Unix Philosophy and your tools pipeline

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

When designing a tools pipeline for your game, you could do worse than to adopt The Unix Philosophy as stated about by Douglas McIlroy.

The way in which we interpreted this philosophy was to separate each step of the pipeline into a single command line application, with a input file ( or set of input files ) and an output file ( or set of output files ). Running your export pipeline then is just a case of defining a script which calls each executable in turn, passing the output of one as the input of the next. You write a GUI that is used to set up the initial options and provide an interface to the user, and as each executable will be writing out to a log file, your GUI can also display the status and any warnings or errors that are generated along the way.


full size

The alternative would be to create a application which does everything. Some sort of Excel for games development. This might sound attractive on the surface. The user has everything under one app, you can unify the UI, the codebase is just one application.

However, this approach is simply not as flexible as the single command line tool approach. Imagine this common situation: you change your export pipeline so now all the models in your game need to be re-exported to match the latest engine.

With the monolithic single application your users would either have to load up each model and hit the export button, one at a time. Or more likely you would have to implement a new feature to the tool, complete with GUI, to allow batch exporting of a set of models.

With the separate tool pipeline approach you can write a script in a couple of minutes that takes a list of models and runs them quickly through your pipeline as a batch process. If it becomes clear that this is a feature that will be used frequently by users then it is no problem to add the GUI part at a later date, which provides a front end to the batch script.

Taken as a whole, implementing that feature fully in both cases is basically the same work. Implement a GUI option, call your model export code multiple times for many model files. The difference is that in the second case, with the simple command line tools, we can get a batch export running in under 5 minutes, then if needed, we can add a GUI later on. With the monolithic app the GUI is a required part of the tool and the coder who writes the new feature must be familiar with codebase in order to implement the feature. When you're in a situation where none of your models work with your game engine and your whole development has ground to a halt, setting up a batch export in under 5 minutes is invaluable. ( Of course if you've managed to get into a situation where someone has changed the model format and brought your development to a halt then you should probably have a think about how your team operates, but still... )

In addition to this flexibility with individual tools you get a built in modularity to your code. If you've decided to re-write your texture processor, simply keep the input file, output file interface the same and you can drop in the replacement very quickly. Decided you need an extra step to your pipeline, after the collision export but before the final compile? Write your new tool and drop it in between those two. Best of all, none of these tasks requires touching the code relating to the other tasks, so your changes will be more stable.

Talking of stability having discrete executables has another advantage in that they are inherently testable. There is no need for complex unit testing frameworks to maintain ( though in another post I may argue that you should have a unit testing framework anyway ). You can automatically test your tools, by running them on a known asset and checking that the result is as expected ( e.g. with a binary diff ). You can then be sure that after making changes to one of your tools you haven't inadvertently broken them.

So to summarise, build your pipeline with the Unix Philosophy in mind and you get:
- flexibility
- modularity
- testability

StageSet coming to Playstation Home

This is going to be awesome

It's really cool to see people doing things in Home that no one could have predicted six months ago. The post says it's out today, so I'm excited to see what people will make of it.

iPhone: automating your distribution build.

One thing I've really grown to love over the years as a tools programmer is the command line tool and automating everything.

Pretty much every C# tool I write is written as a dll with a command line exe and, if needed, a GUI exe. That way I can simply string all the tools together in a script and be sure that I'm running the same code as when the users are going through the front end.

So when I started developing stuff for the iPhone, one of the first things I found myself needing was an automated build script to create our distribution builds. Ready to give out to the team members without access to XCode.

The one problem I encountered briefly was zipping up the app bundle which I then added to our Subversion repository. Previously I'd been right-clicking and selecting compress. It didn't take me long to find the answer.

Also my build script sets up the correct Entitlements.plist and restores the original one back. This is very important as it can effect your normal build and debugging if you aren't careful.

My folder structure looks like this:


# Output of build process
/trunk/MyApp/build/Distribution-iphoneos/MyApp.app
# Build script location
/trunk/Tools/Scripts/dist_build.sh
# Entitlements file which is used for distribution builds
/trunk/Tools/Scripts/Data/Entitlements.plist.DIST
# Zip file which is added to Subversion
/trunk/Build/MyApp.zip


And this is my super simple build script:


#Set working directory
cd ../../MyApp

# Backup existing Entitlements.plist
cp Entitlements.plist Entitlements.plist.BAK

# Copy Distribution Entitlements.plist
cp ../Tools/Scripts/Data/Entitlements.plist.DIST Entitlements.plist

# Build
xcodebuild -configuration Distribution -sdk iphoneos2.2 clean build

# Change to app directory
cd build/Distribution-iphoneos/
# Remove previous zip
rm MyApp.zip
# Zip up the app bundle
zip -r MyApp.zip MyApp.app/

# Copy to location for Subversion
cp MyApp.zip ../../../Build/MyApp.zip

# Restore from Backup
cd ../../
cp Entitlements.plist.BAK Entitlements.plist