Interview 2

Name: Bob Pape

Role: Programmer known for ZX Spectrum version of R-Type.

Website: http://bizzley.imbahost.com

My name is Bob Pape and I was, for a period close to sixteen years, a self-employed freelance games programmer. I started in 1987 writing commercial games for the UK home computer market, specifically the ZX Spectrum home computer, and then went on to code for consoles, handheld devices and the PC. For the majority of that time I was represented by an agent, Jacqui Lyons of Marjacq Micro Ltd. who lined up contracts for me, took care of negotiations and (often) chased after outstanding payments I was owed - even when she wasn't due her 15% agency fee of the final amount! Not having to deal with that side of things too much freed me up to concentrate on coding though being a freelancer meant I didn't always have the resources to call on that I would have had I been employed directly by a software development company. As a result I usually had to source my own graphic and music assets from similarly self-employed individuals in the software industry at the time - which meant finding people who were available and could supply what I wanted, arrange contracts with them, work out delivery schedules and of course pay them. To keep track of the money side of things I ran a small daybook that I handed - along with a load of receipts and invoices - to my accountant at the end of the tax year who did her magic and told me how much to pay the Inland Revenue and HMRC, something I would recommend to anyone looking to make money by writing software.

I left the software industry in 2003 when it just wasn't viable to be a freelance coder any more, which means I have had very little involvement with writing games or producing software since. But times have changed and the increasing market for independently produced apps and games on platforms such as Apple and Android means the days of the bedroom coder and small software teams are coming around again. As much as I would like to think that there has been a vast improvement in how people who write games are treated by those who pay them I suspect that a lot of the core problems are still there, so if what follows seems out of date or obsolete then remember the words of philosopher George Santayana - "Those who cannot remember the past are condemned to repeat it."

What are the most notable software related projects that you've worked on?

For those with an interest in retro computing and long memories then I suppose my involvement with various conversions of the R-Type arcade games from IREM is what stands out for most people. Now I really have to qualify that by pointing out we are talking about a very niche group of people here and of software that was written well over twenty five years ago so I always try and remain realistic when talking about 'The Good Old Days' and try and keep things in perspective. Over the course of my software career I wrote thirteen commercial games as well as a number of others games and programs that were either for myself, given away or ended up being cancelled at some stage for various reasons and I'd class only a few of those as being notable, at least to me.

My first commercial release was a conversion of the three-player arcade game RAMPAGE from Bally Midway for the ZX Spectrum and then followed that up with another Spectrum conversion, of the original IREM R-Type arcade game. I've written at length about the gestation and my experience in coding this second game in a freely available e-book so I won't go into too much detail here other than to say it seems to have stood the test of time and even today I get messages from people telling me about their feelings on playing this conversion back in the 1980's.

A few years later I converted the sequel to R-Type for play on Nintendo's original Gameboy handheld console, and a few years after that worked with friend and fellow coder Jas Austin in updating an enhancing both this and his Gameboy conversion of the original R-Type for the new Colour Gameboy machine under the title R-Type DX. I coded two puzzle-based multimedia titles for the PC that were officially licensed by MENSA, the society for members with high IQs, which have had a long life (you can still find them for sale on Amazon) but I doubt if they'll run on modern computer hardware. Unless you're on some kind of royalty deal then you'll have a hard time finding out just how many copies of your game has been sold which is why the two versions I coded of the Sega Megadrive\Genesis game PGA Tour Golf and it's follow up for the Sega Gamegear handheld and Master System console are notable to met. Actually I was on an 'advance of royalty' deal where you're offered an amount based on an assumption of how many copies they think will sell and you only start collecting on the royalties proper once that figure has been reached. It's been a long time now so I don't think I'm giving too much away if I clarify that by saying my deal was that I received $60,000 outright for writing the first PGA Tour Golf game, based on a royalty figure of 50 cents per unit, and once total sales had reached 120,000 then I would be paid for anything over that. If sales didn't go over 120,000 then I'd still keep the $60,000. If I'd gone for a straight no-fee royalty deal then that 50 cents per unit would have been a bit higher but I would have been paid solely on how many units it did sell so (to simplify it a bit) you have to look on it as a gamble on how good a coder you think you are and how well the product will sell as a result. This particular game actually sold 111,000 units in total so I came out slightly ahead of things in the end. For completeness I'll add that you may be offered a non-royalty deal which will usually be higher than advance royalty figure so again you have to decide on how well you think the game will sell in order to come out with the most money.

What type of technology and software development have you been involved with?

Apart from my brief sidestep into PC projects I was mainly involved with the development of 8 bit software, concentrating on the Zilog Z80 processor, which turned out to be a good choice because it and similar processors were used in a lot of the lower end home computers and games consoles around at that time. In the early home computer years there weren't really that many specific game development tools around - and those that were tended to be quite proprietary and relevant to certain games only - so a lot of coders ended up having to write their own. My development schedule for a game usually included a couple of weeks at the start to give me time to put together the sprite, tile, map, level etc. editors that I'd be need to write the game. Only the really big software houses had the luxury of supported in-house development tools as well as libraries of sound drivers, tape loaders, joystick handlers etc. that the rest of us usually had to put together by hand or pay someone else to provide. For most of my games I used a development system called PDS that was a PC-based cross assembler that let you compile and download to a target machine via a parallel interface but for some consoles I'd use hardware specific kits, all of which basically emulated a cartridge plugged into the target machine but let you develop and compile your source code on a connected PC and send it down to the kit quickly and with little fuss. At some point you usually had to plug the real thing into a console which meant programming and burning EPROMS which was done with a SCSI-based writer and a UV box to wipe the chips. For some of my later games I used software emulation of the target machine on the PC rather than hardware, which was easier than having to squint at the small screen of a handheld device all day, but again you always had to try the real thing in a console as you went along which was when you found out how good (or bad) the software emulator you were using really was.

What are the best types of project to work on?

That's easy, the ones where you get paid! Seriously though, there are some basic rules you can follow when deciding on a project, first of which is to decide if you are actually technically competent to code the thing. I found out what my coding strengths and weaknesses were quite quickly and some of those weaknesses were in computer AI and 3D mathematics so I tended to stay away from the types of games that required them in large amounts. I once turned down a soccer game because I knew I wouldn't be able to implement the computer team's A.I. to a level that people wouldn't laugh at so sometimes you have to be realistic about your competence and just walk away rather than have your name linked to a piece of crap that you just couldn't manage properly. Another thing is to have actual enthusiasm for and an interest in the type of project you've taken on rather than just putting the hours in for the money. If you're going to be spending weeks or months writing code for something you don't really care about then that is going to come through in the finished result as well as being an unpleasant experience during development. This sounds as if it would be self-evident but I believe a lot of game coders can remember when writing games stopped being fun and started being hard work. You might want to look at whether the project you've started actually stands a chance of being finished and published, a fate that hits a lot of coders near the end of the life-cycle of the machine they're writing for when someone decides that it would be cheaper to kill it off and cut their losses rather than try and sell it to a shrinking market. I've been involved in a project that suffered this fate as well as another that got pulled for 'political' reasons, and of course companies go bust all the time, but it can really damage your self confidence if something you believe in and have spent months bringing to life never sees the light of day as you view every project after as a gamble. People say you need a good support structure as well and I agree with that, it's too easy to fall into the trap of thinking you can handle and control everything yourself - especially if you've had some success in the past - and that you don't need significant help from others. When you're a one-man-band outfit like I was then you don't have a choice but it's just plain stupid to turn down help and support when it's there for the asking.

What software methodologies do you recommend using for software projects?

One of the things that personal computers did was to break the accepted way of writing software, something that came a bit of a surprise to Atari's American lawyers in 1981 when they sued gaming company On-Line System for distributing Jawbreaker, (what they saw) as a knock-off of their licensed game Pacman. On-Line owner Ken Williams was asked by an Atari lawyer "wasn't it a fact that typically the programmer who's designing these games at least produces a flow chart and then writes out the source code manually prior to punching it in?" and seemed almost incredulous when Williams told him his coders were typically too lazy to make up any sort of flow chart and just started putting routines in wherever they liked in any order. Today most large software projects have more in common with those pre-1980 days than the bedroom coding of the following decades in that everything has to be pretty much pre-planned and locked down before starting, which seeing as a lot of these games resemble movie films in size and complexity is really the only way to do it if you want control over the hundreds or thousands of people responsible for the finished result. Is that a better way of writing software than being spontaneous and adapting to things as you go along? Of course not, nor is it worse, it's just that different sized projects require different approaches in order to get the job done so there's no one way to do things, you use whatever approach you know will work.

I learnt my computer trade on mainframes in the 1970's so I had a lot of the really basic stuff drummed into me right from the start. Of course a lot of that is now obsolete (I no longer need my IBM flowchart template for designing programs) and there have been many books written on this subject alone so my methodology for writing software is quite personal and, while I can say it worked for me, I don't know if it's relevant any more. Taking things from the point of actually having the project green-lighted (and getting to that stage is a whole other story) then I would spend a week or so just walking and talking to myself about what was needed and how I'd do it - which probably got me a lot of odd looks from the neighbors but I found it easier to do this than just jump straight in and start coding. When I was comfortable with the approach I'd use and some of the technical problems sorted I'd sound out those ideas with others connected to the project, mainly my graphic artist and producer, to see if it made sense to them as well. This is where a solid knowledge of the industry you're coding for comes into things because if I'm trying to explain my game mechanics by referring to other past games then it really helps if everyone knows what you're talking about right away and can chip in with suggestions and even reasons why that approach wouldn't work. Just because someone isn't a coder doesn't mean they don't have knowledge and experience of the market you're coding for so it's always worth sounding your ideas out with others who've been around the block a few times.

Once a project was started then my methodology was pretty simple really, code what was needed to reach the next milestone and get paid! Since I was a freelancer my contracts were based around development schedules and payment milestones based on those schedules so it really was as simple as making sure routines X, Y and Z were in and working by a certain date to keep everything running to schedule. I had enough faith\arrogance in my abilities at the time to lay out and schedule my games at the start of a project and come up with milestones that would cover the complete development of the game and that I knew I could hit, or at least have my excuses ready if things slipped a bit! I was fortunate in my software career never to have gone over the final deadline by any significant amount (and software companies lie when they give you a final completion date anyway) and never really had to work to anybody else's way of thinking. There were a few times that proper Project Management was used to control my games but from my side of the screen I didn't see any advantage, or disadvantage, to this approach and the constant stream of requests as to how I was doing and resultant Gantt charts meant nothing to me. The Basic Rule is you do whatever it takes to get it done.

What signs have you learnt that indicate a project may be problematic?

Before it starts I'd say a project specification that is TOO detailed, where everything is broken down to the n'th degree or timed out to the last hour. You just can't have that micro-control over a large software project and expect to hit every target and it's when you don't, when you start arguing the schedule rather than the code, that's when things get out of control fast. Over confidence at the start is another, it's one thing to be enthusiastic and 110% behind something but when you're reading the project spec. and come across "this is going to be the best game ever!" or "revolutionary software innovation" then someone is going to end up disappointed and someone else (i.e. the coders) are going to get the blame. Some people say to check out a company first or talk to people who've worked for them to get a feel of how things are but that's a purely subjective process, just because someone had a bad experience doesn't necessarily mean that you will, though if everyone is telling you the same negative things about that company then alarm bells should definitely start ringing.

Indications that there may be problems once you've started pretty much fall into the basic business category, they're not specific to software productions (though there can be some) but typical of business practices in general. Not getting paid on time, being given excuses instead of assets, breakdown in communications, loss of key personnel, - you don't have to be long in this or any other business to see the signs that things aren't going to work out. Something more specific to software is the changing of the initial spec. especially if the change is an increase in what has already been agreed. By the time you're dropping deadlines and cutting stuff then your project has gone from 'may be' to 'definitely is' problematic but when someone starts adding things or saying "wouldn't it be great if it did this" then you know that's not going to end in a good way. Now I want to quantify that by saying the resulting problems are not necessarily major ones, it could be something as simple as having to work a weekend when you had other plans, but as you get further into a project and nearer the finish line then any irritant, large, small or even imagined, can be the final straw that sets everything off. Coders working too long hours in the final stages of a project can be tired, stressed and wound up so tight that it takes hardly anything to tip them over let alone adding or changing things to a schedule that was supposed to have been locked down months ago.

What strategies do you use to avoid problems and/or keep them under control?

There's no way to avoid problems completely so the best you can do is try and minimize the damage and make sure you stay on top of things - unfortunately by the time you're aware of a problem then it's already too late. You can't deal with every eventuality, just how do you plan for (say) a colleague who breaks a wrist while playing football and can't type properly for a month, so for that reason it's no good trying to list and counter every problem you think might arise beforehand because you'll never catch them all and you'll be wasting your time planning for eventualities that will never happen. What I tended to do at the start of a project was talk to the people involved and be a bit negative about everything because if I could 'break' things just by talking about them or point out some of the more problematical areas that I saw then at least we had advance warning that we might be in for a rough time or knew what to look out for. This approach can make it seem that you aren't totally behind a project when what you are trying to be is the little boy in the story of the Emperor's New Clothes pointing out what everyone else is too afraid or reticent to say. It's one thing to have high morale during a project but it shouldn't be at the expense of what is really happening.

There will always be problems no matter what approach you use but if the level of problem you encounter is along the lines of running out of coffee or your mouse stops working then that really isn't worth bothering about (but see what I wrote above about minor problems at the end of a project.) We all make mistakes now and again so playing the blame game or trying to find out who was responsible for something going wrong is a bit of a waste of time as well, it makes people feel bad and can seed discontent that will fester so it's just not worth it.....unless this is becoming a regular thing with a person\supplier\piece of software\whatever in which case it's time to cut your losses and find someone or something else that will do the job instead. This is a preventative measure really and you may not be in a position to take it in which case you just have to grit your teeth and be prepared for something similar to happen again. I really only had one strategy when it came to dealing with things that weren't going the way they were supposed to and that was a phrase I picked up from somewhere or other:- "if you can't find the solution, change the problem" which served me well for many years. I don't know where this fits into accepted problem solving techniques or crisis handling but the approach that the way to get around a problem that can't be fixed is to change it to one that can be, though it sounds a bit simplistic, is something that worked for me many times. The tricky part is coming up with alternatives that are both workable and acceptable and this is where you find yourself compromising or doing things you hadn't planned to. It's that triangle you see in all managements books with Cheap, Good and Fast at the corners - you can't change one without affecting the other two.

How do you manage your workflow?

On a large scale, over the years I've tried different ways of working - keeping to office hours, working a certain number of days a week, working only nights etc. and all of them work.....at least for a while. Unfortunately software development is one of those jobs where most of the hours have to be put in towards the end of a project so whatever approach you use gets cast aside as you work all the hours necessary to bring the thing in on time. What you also have is that someone else, usually your Producer, will be trying to get you to meet your schedules no matter what, which is great if everything is going well but falls apart if you're having trouble with code or concepts. Then you'll be 'asked' to do all sorts of things to stay on target and whatever workflow system you had planned will be out the window, which can also happen if there are others involved in the production process. If you are looking for people who will supply you with assets when you actually need them rather than when they feel like it or who will tell you the truth when it comes to future delivery dates then that does require good forward planning.

On a day to day basis then you do have to have some sort of rigidity in place otherwise you end up only coding when you feel like it, which is a sure sign that you've got problems. I prefer to work in the nights: there are less distractions, everything's a lot quieter and what's on the television is usually so bad that you have no choice other than to stay on the computer! When I started coding nothing actually flowed as such, it was all stop-start as I was working out how to do things for the first time and a lot of it was actually trial and error but as I completed more and more games things got a lot smoother and I became more confident in my abilities. That's just me though, there are talented coders who can sit down and come up with what they want with no effort, if you do it long enough you find out what your level of competence is and work to that rather than any particular system. But a lot depends on where you're working and what kind of social life you have (or should that be want?) so if you have family or a relationship to deal with then you've either got to work with that in mind, find a compromise or lock yourself away and suffer the consequences. Game coding is probably suited more to young people because they tend to have less personal and social ties and can work long hours and unusual shift patterns and (generally) the only people being affected are themselves. Once you have a partner or a family and responsibilities then it gets much harder to put in those all-nighters and twenty-four hour sessions and if you insist on doing so then something is going to break and it might not be you.

Do you have any strategy for managing the amount of incoming work you have ñ i.e. to avoid not having any work and to avoid having too much work?

I was lucky in that by my third game I was being represented by Jacqui Lyons at Marjacq who lined up the projects for me so I never had to worry about having too much or too little to do. In the early days of game computing it wasn't unusual to have a coder work on more than one project at a time, if for no other reason than games were much simpler then so it wasn't too much of a stretch, but I always stuck to one game only because I felt I could never do both justice if I was working on two. Actually that's only partially right as I think I felt deep down that I wouldn't be able to keep track in my head of two different projects simultaneously and I wasn't about to take a chance and take more than one on just to find out if I was right or not. I have a recurring dream to this day that I'm working on two games and the unfinished first has been forgotten in the rush to finish the second so there must have been something to it after all! I wish there was actually a strategy to avoid not having any work but until you can actually force people to employ you I don't think it's going to happen. The way you usually got work was based on how good your previous efforts were (as we were always being told, "you're only as good as your last game") but the limited life of early home computers and games consoles meant you had to adapt and shift platforms fairly regularly.

If you were moving to a new machine then somebody had to take a risk with you on that first project which is where personality rather than ability sometimes decided if you got the job or not. Just because you could produce product for home computer X didn't necessarily mean you could do the same for games console Y so it sometimes came down to how well you'd got on with people in the past as it was pretty common then (and perhaps today) in what was a small tight-knit industry for one company to phone up another and have an informal chat about somebody and whether it was safe to employ them or not. Often though one coder usually knew another - or knew of them - so if asked could pass an opinion of what they felt or heard about them and what they thought about their previous games.

What factors do you use to judge credibility of professionals you speak to?

The one that matters to me the most is whether you can work out what they're talking about is based on actual experience or if they they've just briefed themselves on it (or are plain making it up!) I can read a book on Kung Fu but that doesn't make me Bruce Lee so - to give an example - I'm always a bit wary around people who talk about writing and publishing games when they've yet to release anything themselves. This is of course the perennial "those that can, do....those that can't, criticize" that you find in all walks of life and it's not uncommon in the software industry to find people like this in charge of things and passing off their opinions as facts. We're all guilty at times of telling people what they want to hear ("yes of course I can code in FORTRAN, when do I start?") and I think a small amount of stretching the truth is only to be expected if you're publicizing yourself or trying to get a contract. What annoys me though is when you can tell someone really has very little idea of what they're talking about yet is trying to give the impression that they do, I'm usually too polite to call them on it but if it's a subject I do know something about then I like to play the naive innocent, be a bit mischievous and start asking questions about it just to see what they'll do. If I can class 'experts' along with professionals here then that's a group you'll also run up against, they usually DO know everything about a given subject (or at least are highly opinionated about it) yet unlike the real world where expertise in a subject usually implies extensive practical experience it's rare to find the same in the software industry. Really it's all down to how you define the word 'professional' in this context, to me it's a person you believe when they tell you something - a delivery date, a payment, a way of doing things etc. - and credibility is something you gift them with rather than accept from them.

What is your definition of a brand?

An identifiable product. But I think that the idea of brand awareness is often more important to sales and marketing departments than the brand itself, that it's not what you've got to sell but how you sell it that's important, and the sad thing is they're probably right. By that I mean you can pretty much sell anything as long as you can get it to appeal to the buyers somehow and that's where the brand name comes in. You see this in computer game sequels or those that feature characters from previous games as well as in hardware, people are more interested in having the latest branded version rather than what it actually does. There's a really easy way to show this....let's say I've written three successful games featuring "Derek the Singing Wasp" and I write a fourth, exactly the same character, but call him "Norman the Musical Insect" instead. Here Derek is my brand, something people can identify, if I market my game as featuring Norman then what do you think my sales would be compared to a game featuring Derek - same product, same graphics, same marketing spend yet different branding? People buy the brand name not the product.

How has the value of a brand affected the projects you have worked on?

Since brands are usually owned by people who would like to give the impression that they take great care in protecting their good name what we're really talking about here is licensed product. Most of the published software that I wrote was licensed in some way, either as conversions of existing arcade games or by using a trademarked or copyrighted name or title which usually means the license holder gets to have the last say about things. The funny thing is that I hardly ever came across any direct intervention by a license holder to anything I wrote, which I would like to believe was down to my ability to give them exactly what they wanted but was probably more to do with them not caring that much about the finished product. In the early days of computer gaming the hardware was usually so underpowered that no one really expected it to emulate the custom hardware found in arcade cabinets so a company could often get away with murder when they released home computer versions of these games knowing that as long as they had the name and a vague approximation of the gameplay then that would be enough to sell. Later on when consoles meant worldwide sales these license holders got a bit more possessive and protective but again my personal experience was that once they'd made their money licensing the brand they didn't care that much as they knew they weren't going to make any more money from that marketing avenue. What intervention I did suffer was usually along the lines of a suggestion rather than a demand and I always said yes, they were the ones paying me after all and I'd give them whatever they wanted. A company that paid more attention to protecting a brand value was Nintendo - not their brands, that goes without saying - but the knock-on effect of distributing games of other companies that might have put them in a bad light. I think all of us who worked on games from Nintendo had to put up with bug reports from them that spotted (what they thought) were unwholesome and unsavory elements that would have people complaining, usually centered around a High Score table. That you had to take steps to ensure that a player couldn't enter swear words was accepted by us all but to be told (and this actually happened to me) that you had to block a certain word made up of random characters because the letters were the initials of an LA street gang was really ridiculous!

Are you finding that people's expectations for what is achievable with apps and web apps are growing? Has this caused problems in your projects?

As I said at the start I left the software industry in 2003 so my answers to this and the following questions are going to be rather short and lacking in practical knowledge I'm afraid, more opinionated than factual I'm still trying to work out when computer programs died and apps took their place as no one seems to code any more, they 'develop', and long-windedly calling a block of compiled code an 'application' to the wrong people is going to get you labelled as out of touch. The majority of people who use apps are quite happy with what they've got and any expectations are more along the lines of being able to say to their mates "my phone does this better than yours" than having a particular need for something they've been waiting years for. Given a choice between an app that can measure your blood pressure or one that can rate your farts what do you think your average app user is going to download first?

In your opinion, what differentiates software, apps, web apps and websites?

The majority of people who use apps don't care about what's inside them or where they come from as long as they do something, and if that something is useful or entertains them then that's all that matters. With more and more companies offering apps that do the same thing as their websites (Facebook, Twitter etc.) we're seeing the slow migration away from browser-based interaction and sooner or later it will reach a point where the only way to gain access to some sites will be via an app, and then there will be no differentiation because there will be no choice.

What makes a good app?

I didn't want to make this a pedantic answer but it really all does depend on what you mean by 'good'. To some cost is what matters most, for others it's the number of features or speed or security or how addictive it is or what your mates have or the what latest fad is or.....I won't go on.....you get the idea. To me end any app you've installed and then not deleted to free up space is about as 'good' as it gets.

Where do you think the industry is heading?

I think development tools are getting easier to use, more point and click than dealing with the intricacies of opcodes and programming manuals, which means quicker production and better looking results but at the cost of homogenized product I'm sorry to say. As it becomes easier for people to produce software then you're going to see more and more rubbish as well, knock-offs of successful products, apps with incredibly limited appeal, a proliferation of non-approved product and of course a shrinking income for companies as an expanded market invariably means a reduced share. What you won't see is any kind of mass take-up of software development no matter how easy you make it because, simply put, the huge majority don't want to mess around with what goes on inside a computer or phone and are quite happy to just play 3-in-a-row games until their eyes bleed. The power and capabilities of computing hardware is going to keep on improving but the games you play on them will be the same old ones you played on their precursors but with better physics, graphics and hopefully A.I. Someone will show you a new game and tell you how different and revolutionary it is, and they'll probably be right, but there's always a seemingly endless selection of car racing, FPS, dance and sports games being churned out to show you what the market really is all about. I think we've passed a tipping point though and that computer\console gaming is here to stay, which has more to do with the vast amounts of money to be made off of Premium titles than any desire to be creative. Then again that was probably being said by video game companies in the 80's just before it all went wrong. Reports of yearly game revenues dropping from $3.2 billion in 1983 to barely $100 million in 1985 show what can happen when you start to believe you've got the market under control

I think software companies will split into two groups, those that can afford the movie-budget costs needed to put multi-format A-title games together and smaller, looser ones putting out quirky or innovative product and everything in-between will go, a medium sized business won't be able to compete with the quality of big budget releases and won't be able to match the lower overhead and development costs of a small company. There'll be a few left churning out filler and advertising-type material but this will be to a market that's not looking for creativity or originality but what they know is safe and reliable.

I think that companies will need to come up with new revenue models and not concentrate on any particular one as a lot do now, if you're basing your income on In-App Purchases and the government or a group with power decides that too many children are spending Dad's money on virtual tat and start making waves then you better cross your fingers they don't decide that banning it is a good idea as you're going bust! Whatever happens there will be a lot more control over the type of material that can and can't be included in products available from large company app stores. People will start being 'offended' by more and more minor things and those companies that see themselves (or would like others to see them) as responsible, protective, majority-orientated entities will respond by restricting what others, or they, deem to be offensive material. There is nothing new in this, companies like Nintendo and Sega have always controlled what they consider to be offensive material in their games, usually to the baffled incredulity of those of us who produced games for them, but as we become a society less and less tolerant of smaller and smaller things this is going to be echoed in the content of apps and software. Not because these companies have a heart or care but because offended people won't spend money on their products.

What are the biggest differences between being employed by someone and being employed by yourself?

I haven't been self employed for thirteen years now but when I was: working your own hours, setting your own goals, no office politics, not having to haggle If I needed something, very little interference from others, choosing what titles I worked on.....basically everything encompassed by the phrase "being your own boss." If I stick to software then it was really only my first two games where I was employed by someone else, and those who have read my account of those times will know what a mess that all turned out to be! But even with those two games I was pretty much left to do whatever I wanted, neither of them had any sort of advance meetings or guidelines as to how things were to be done I was just given the name of an arcade game and a time limit and expected to come up with something as close to the original as possible. I really hope things today are different as that is no way to run any sort of company and perhaps I was just unlucky enough to choose one that operated that way when I started out and assumed that's how all the others did it. One thing you get as a sit-down-at-the-office-and-work employee though is constant monitoring of how well - or not - you're doing, which you can either view as beneficial or somebody always looking over your shoulder. You also reap the benefits of a regular wage, chances of advancement, the company of like-minded colleagues and no need to go looking for work - if all is well and good. Self employment can be a bit of a gamble, comfortable living when there's plenty of work but less so when times get hard, and you do have to do everything yourself which can be a bit daunting when you realize that a company is spending possibly hundreds of thousands of pounds on production, advertising and marketing of a product that you have pledged to deliver in six months time, fully working and exactly to specification as they require. The Christmas party tends to be a bit of a solitary affair as well.

How did you detect people who may waste your time and how do you deal with them?

Unless you're particularly gifted with some kind of ability to spot timewasters from the off then unfortunately it's all down to experience. If you're just starting out and someone says, for example, that your graphics will be ready in a week then who are you to disbelieve them, but when you've gone through this a few times and you know that it's more likely to be two weeks than one then you know you're being told what they think you want to hear rather than the truth. This also happens with companies looking to employ you, not out of any sort of malice it's just that's the way they work, so you end up putting bids in for projects that you know you won't stand a chance of getting just to stay in their good books and hope they'll think about you when something else comes along. Sometimes it's not the fault of the person you're dealing with, they may be waiting on somebody else to close a deal or supply them before committing to you which is annoying but there's nothing you can do about that except wait along with them. Perhaps I'm naive but I find that people in general don't set out to deliberately waste your time, quite a few of them have a lot of enthusiasm for some idea that to them makes perfect sense - but is obviously unworkable or under funded - and they're looking for someone to listen to them and say yes. I had that once with an amateur author who came to me looking to turn his work into a PC game, to him it was a sure-fire winner but I gently had to explain the realities (and costs) of creating a game and instead came up with a multimedia-type solution that could have been done relatively cheaply instead. I guess that since I wasn't on board with his ideas it meant I was negative about it all as I never heard back from him but I was happy to put some time into it since it obviously meant so much to him.