A collection of things I’ve written.

20 years of a Video Game Developer’s Career – Part 4

9 min read

I’d like to share with you my game development career experience as part of a series of posts, let’s rejoin the story at during the twilight days of PlayStation 2 when I started at Kuju in Sheffield. I’ve included a lot of photos in this post so you may even make an appearance!

Kuju Sheffield v1

I was fortunate to be have formed strong relationships with people across the industry and I was brought in as employee #2 for the newly formed Kuju studio in Sheffield where the next phase of my career began including many of the people I’d worked with in Leeds on the emerging platforms.

Kuju had recently been listed on the stock market and was expanding rapidly with studios in Guildford, London, Brighton and now Sheffield.

Starting out at Kuju Sheffield was an exciting time, there were essentially 4 of us in the 1st few weeks holed up inside a tiny office under one of the stands of the football stadium for Sheffield United. The room was long and thin with only a high tiny window at one end and it was very reminiscent of the early days of my career back at Alligata.

In this tiny space we not only crammed ourselves but an immense server rack that was built for the future, the server itself was incredibly noisy and it appeared to be made even more so by the small environment. The room soon became hot and noisy but we were enjoying ourselves.

Dave, Nick, Tony and myself beavered away making a few PS2/X360/PC ports for the main Kuju office while we found our feet and got our own projects, which didn’t take long and we were expanding quickly.

  • Date: 2003
  • Role: Anything going
  • Studio Size: 4
  • Projects: 1
  • Platforms: PlayStation 2, XBox, PC

Kuju Sheffield v1.1 Within a few weeks we expanded into a larger office on the same floor that took us up to about 15 people before we needed to move again. We were working on a football game for Codemasters at this point and we started to bring in some great staff who were unfortunate casualties of the demise of Warthog studios. It would turn out that we’d stay together for many years and we had a great time.

Working under a football stadium posed its own challenges with the most prominent one being that we weren’t allowed in the building during a period of 2hrs before to 2hrs after a match! This was particularly frustrating when we had deadlines to hit as we were simply evacuated from the building. As producer/project manager, I even went to the extent of planning the milestones to avoid home match days.

The servers furiously buzzed away in the corner and we delivered the game on time and this won us another contract.

I was named as Technical Director at this point but I was pretty much doing anything that needed to be done: building desks, installing cabling, running servers, finance, business development, training, project management, programming and a load of other stuff. All the stuff everyone does in a small business and it was fun.

We delivered the game on PS2 and XBox as a team and we were hungry for me but we really need to move out so we relocated across town into the posh Media Center.

  • Date: 2003
  • Role: Anything going
  • Studio Size: 10-15
  • **Projects:** 1
  • Platforms: PlayStation 2, XBox, PC

Kuju Sheffield v1.2 Our studio increased quickly over the next few years peaking at about 40 staff across 3 projects being made on PC, PSP, Xbox & PS2.

We had specialist staff now and we started to get some real traction.

We were making a Flight Simulator for PSP, Football Action game for console, Football Management game for PC, Social Quiz game for PS2, Fitness game connected to a cross-trainer, TV<>game cross-over pilot and lots of little trinkets on the side.

People came and went but we remained pretty stable and everyone appeared to be enjoying themselves.

My named role as Tech Director was now largely being done by one of our original lead programmers where I was pretty much acting as Dev Director, setting out production process, managing finance, working across sites and a myriad of other things.

I attended frequent meetings with the Execs at Kuju presenting projects, new business and finance reports all of which I’d prepared and ran. I had good relationships with our clients as I was their day-to-day contact.

I was also getting more involved in the people side of the business again, hiring, firing, reviewing and applying the regular attention that an active group of developers required.

Despite all of this, we were struggling to get in new work along with many other developers and the prospects didn’t look good.

  • Date: 2005
  • Role: Anything going
  • Studio Size: 15-35
  • **Projects:** 3
  • Platforms: PlayStation 2, XBox, PC

Kuju v2.0 - The King is Dead What happened next was a blur of rapid change.

Our incumbent Studio Manager retired and I was asked to take over as I’d been doing a large part of the work anyway. It didn’t feel like much of a change for these reasons and I relished the opportunity to take the studio forwards.

I made a promise to everyone: I would take us into a new era and get us a ‘next-gen’ project, we would do this by standing on the shoulders of Unreal 3. We would develop expertise in this area that would benefit us all.

Numerous people shifted around within the studio, backfilling all the positions and this gave everyone a new round of energy.

I worked hard over a few months and I got us another contract - this time it was significant as it was on ‘next-gen’ consoles and represented a massive improvement in our prospects. We all relished the opportunity.

We began work on our game, really pushing ourselves and learning new platforms and new ways of working.

We rapidly ran out of space and we outgrew our offices where the main problem was that our expansion had caused us to take on additional, separate, offices in the same building. This was workable previously as we’d been split across 3 games in 3 offices so it kinda worked but it failed when all of us were on 1 project.

In hindsight, this is a great way to scale up. Take on multiple small projects then combine your team to make a larger team for a single project.

So, I hunted around for a new home for our studio and I found one just around the corner.

  • Date: 2005
  • Role: Anything going
  • Studio Size: 30-35
  • **Projects:** 1
  • Platforms: PlayStation 2, XBox, PC

Kuju v2.1 - Custom Fit Office Our new offices was brilliant. I managed to find us a large open-plan space and I planned the floor space incorporating meeting rooms, a small office (for me), storage space, kitchen and other bits and bobs. We got to choose the colour scheme, flooring and everything! Of course I can’t claim sole ownership of all of this.

Our Art Director, Nick, and Tech Director, Dino, and many other people played a key role in making this a success.

It took a few weeks to come together and we were so excited to be moving, even it if was just around the corner.

I think it’s safe to say that we enjoyed our new space.

We had exciting times too, we had people trapped in a lift and had to call out the fire brigade that amused everyone except those trapped and we there was also a MASSIVE fire opposite our building and we just watched from our windows.

During all of this we were still working on our game and all of our other commitments but it all seemed to gel.

I structured the studio to be as agile as possible and we started to invade the new territory of Outsourcing the artwork that very few people were doing at the time. It just made complete sense.

Meeting the Stars Our football game was a dream come true for a handful of us as we went to Barcelona and Milan to go behind the scenes of the largest clubs at Barcelona, Inter Milan and AC Milan to capture reference of the stars. From all 3 teams we got to meet all the stars, agents and managers, take detailed reference photos of everyone from many angles. We even went out for dinner with Lionel Messi!

Kuju v3.0 - becoming Chemistry

The higher-level business was going through a transition. The many Kuju studios in London, 2 in Guildford, Sheffield and Brighton all had their own niche and identity and it was becoming increasingly confusing for us internally and it also must have been very strange for our prospective clients. We would attend meetings and say “Hi, we’re from Kuju and…” …. “Didn’t we just see you guys?” … “No, that must have been one of our other studios…we specialise in X and would like to show you Y”. etc.

Re-branding was the order of the day, Brighton went first and became Zoe Mode and we followed on quickly afterwards changing our name to Chemistry.

The name Chemistry worked for us, it represented us bringing together different elements of a game and making something new and never experienced before. It solidified our messaging and provided a great identity for us as a studio to get behind. We had banners, marketing, press, t-shirts and a whole range of other things branded up. Our offices were white, clean, sterile with a few hints of colour.

Back on the floor, I’d also been pushing new contracts and we were now working on 3 separate PS3 and X360 games. We had an FPS, a Football game and we were also helping Midway out on one of their projects.

As a studio, we were immensely busy and the amount of personal work was stacking up plus I was aiming to keep everything on an even keel.

Due to the nature of working as a remote office, as well as running 3 next-gen projects and running a studio I was left also doing Office management, HR, finance, answering the phones, ordering toilet rolls, managing servers, doing the post, fixing desktop systems, building furniture among other things.

As management, there was myself and 1 other Project Manager doing all of this together. You can imagine what this did to me as a result.

  • Date: 2007
  • Role: Anything going
  • Studio Size: 35-40
  • **Projects:** 3
  • Platforms: PlayStation 3, XBox 360, PC

Enough is enough

Despite great prospects and a wonderful team, I’d had enough and I worked with the Execs to bring in Mike as a replacement Studio Head and I sadly quickly left the business with nowhere else to go. These were tough times and sometimes people just won’t listen to repeated cries for support and see the issues that are staring them right in the face. It sometimes takes a drastic measure to make people realise what’s going off.

So, I left Kuju and a great team. My time at Kuju was the happiest and most complete I’d ever felt and it felt like I’d let a lot of people down but I had to move on.

What next? Across to the dark side

The next phase of my career was completely unknown and it took me a few months to find a role that suited me. I was fortunate to have 2 great offers: 1 from Codemasters, 1 from Sony. Which one did I take?

This is where we’ll join the story next time…

A few memories

Further Reading

A warm fuzzy feeling

I always get a warm fuzzy feeling when I get to know that people enjoyed the games I made all those years ago…in todays world it’s relatively easy to find people who were previously shrouded in mystery and you could never reach them.

Do you connect with people who make things you enjoy? 

Arabian Knights (via satansam@YouTube)

Just a little message to say this game was one of the staple games of my childhood. There was one level I could never get past, I think it was on a pirate ship... by that point in the game I had no lives left so it was a struggle for a 10 year old xD. But yea. You programmed a brilliant game. Every part of that game was well made, the controls, the music, the artwork. Great stuff. So with that in mind, cheerio!

Epic Citadel - lean, mean development

2 min read

epic-citadel-004 The recent outing on iPhone of the amazing looking Unreal Engine 3 demo entitled Epic Citadel (available free) by Epic really shows the underlying capability of the hardware that current mobile devices have. In short, it’s like nothing you’ve seen on any iOS device so far. But is it all good for game developers?

I’m reminded when I see such apparent wonders of technology that actually, this is what most developers can achieve if they’re prepared to go as low down in the API as they can, right down the HAL if possible. The closer you get, the more layers of noisy slow API you get past and the more precious CPU & GPU time you get to spend on your content.

I’m also reminded of the fat, lazy techniques that it’s easy to get away with when you’ve got a lot of CPU & GPU power to play with on most non-portable systems such as PS3 / X360 / PC / Mac.

Why bother to optimise your artwork, level design, code when you can just let the video card do all of the work for you? This is a bad attitude.

Sloppy implementation really hurts handheld devices and the best teams know how to be lean with their systems and really squeeze every ounce out of the available hardware. This is generally good practice anyway.

As an example for iPhone; If you can, go straight past COCOS2DUnity / Prime to EAGL and Open GL ES. From here low-level code, smart techniques, clever level design and diligent artists will all combine to get you a great, fast experience. I appreciate it’s tougher to do but the benefits are worth the effort.

If you’re not careful, the danger then is adding in fat such as scripting languages such as LUA or UE3 Kismet (Unreal’s embedded scripting language) that cost you performance to interpret at run-time.

You should also consider the type of game you make. I’ve personally work on a few UE3 titles and from personal experience, and  many game devs will tell you, UE3 is great at making Gears of War type games. The further you get away from doing short-view FPS games, the more and more of UE3 you have to re-write to make it work. Just ask the team on APB who tried to make an open-world MMO using it.

Try and think about this when you’re setting out with your system architecture and you’re choosing your low-level systems that you’re going to build everything on top of. Make sure it’s right, make sure it’s going to stand the test of time and get the game *you* want to make.

Check out what can be achieved in just 4,096 bytes if you try.

Avoiding Redundancy 2

2 min read

I very recently wrote a post entitled ‘Why Does Redundancy Always Happen In Game Development?’ that kinda hit the spot with a few people and I think it needs more context so I thought it worthwhile giving a separate update.

It’s a tough topic to discuss and it always has negative connotations but it’s a fact of life and ignoring it and not being prepared is a bad thing.

GamesBrief Job Loss Tracker - 3/Sep/2010I can totally see how the provocative title and lack of context could have riled some people so here’s some context. Redundancy is obviously a real and horrible event that happens and it can be mitigated by properly running a business but it’s largely inevitable.

My recent experience is based around running mid to large-scale teams of 30-80 people across multiple projects and the level of commitment that goes with that. My focus is on quality, delivery and profitability of all the work I do. The original post was intended to make people aware of the fact that if they do not consider what happens at the end of a project and blindly go off on a creative whim then don’t be surprised if your business fails. This is obviously fine if you’re motives are purely hobbyist and you never intended to be a business, or stay really small anyway.

Outside of the hobby developers making video games is an “industry” about making money, for which you need to “shift boxes”. As much as we like to think we’re being totally creative, most people in video games only do this so they can pay their bills. After all, we all need to live somewhere and pay for food for which we need money, that we get from making games, that people buy.

It’s actually a “box shifting creative industry”, I completely support that as it’s ultimately creativity that sells games and the 2 are intrinsically linked. There is 1 more important criteria though, which is quality. Quality sells games like hot cakes and there are many factors towards driving quality upwards. Oh, and marketing, good marketing will sell the most un-creative/poor quality things as I’m sure you’ve witnessed. Oh and the aqueducts. :)

During my career I have seen all the problems occur in business time and time again from big businesses through to small businesses, I’ve occasionally been part of the mess and more frequently seen others get caught up in the demise of a company. In pretty much all of these cases it’s been avoidable.

Businesses, regardless of what they’re doing, need to be agile and able to cope with the ebb and flow of the demands during the production lifecycle. Smart use of outsourcing, freelance / contract staff in the right place and prove fruitful and help you’re business remain stable and able to weather the storm. I have strived to ensure that projects and I run and businesses I’m involved with consider this and mitigate the risk of redundancy where possible.

Thankfully, redundancy always presents new opportunities and it’s time to pick yourself up and get back on the horse. After all, what doesn’t kill you only makes you stronger.


Leveraging Social Media To Maximise Your Game Sales

3 min read

Connecting with your audience is absolutely critical to the success of your game and is something you should take seriously and adopt a professional understanding. I’ll cover some of the high level points here and provide how to maximise social media communication for different business types.

Why Does Redundancy Always Happen In Game Development?

4 min read

It’s worth understanding why redundancies are a natural consequence for an independent studio when they finish a project.

Firstly, it’s important to understand that the end of the project is always the point when the team is the largest, QA come onboard, people are generally added to get the project delivered to a high enough quality.

So, what happens when the project ships? What do all of these people do? As much as we’d like to believe that 100% of the team have meaningful work, it’s not going to be the case. With the best will in the world a studio will plan follow-on revenue generating work but it’s incredibly rare that this work magically dove-tails into utilising 100% of the available team, or even a reasonable chunk of the team. Support work, patching and concepting future projects may all soak up some people but all of this work is still supported by the revenue of the game that’s now shipped and the cash flow has likely stopped.

It’s quite common for studios to work for payments that are milestone based and low margin so they can remain competitively priced and also pay the wages but this money stops at the point of delivery. Some games are developed against an advance for royalties that usually means the game was developed for almost no profit on the basis of a big upside should the royalties kick in. Publishers are generally not interested in paying for your team to idle around between projects, they want to pay for the work only and even then it needs to be competitively priced.

The danger is obviously the low and frequently negative profit margins during development that don’t provide a buffer to get the studio through the gaps between work.

Imagine you’ve made a generous 15% net profit over the life of the project and you haven’t spent any of this money on other things and it’s just sitting in the bank. The obvious extension to this is that if nothing changes you can remain open for 15% of the projects duration before your cash runs out and you’re bankrupt. So, if you’re project took 9 months to make, you’ve got enough money to fund you through a gap of 1 month. Using this example, if the team is reduced to 25% of its size then the money will last 4 times longer for those that are still resident.

In reality, it’s not that straight forward because there’s a lot of other factors coming into play and you’ve now got a big team in place and a lot of mouths to feed so you’re commitment is high. No business operates in this way and net profit doesn’t go into the bank for a rainy day. It’s typically used to fund other opportunities to expand the business such as paying for over promising / under delivering, concepting, attending conferences, preparing pitches, R&D and a load of other things. Making people redundant also costs money too so it’s not something a business can enter into lightly.

So, the natural conclusion is that a studio can’t operate by employing 100% of the team 100% of the time and support that entire infrastructure when there’s little or no money coming in. It’s simply not going to work.

The only sustainable way for single project independent studios to keep this going is to operate on a Core+Contract basis where everyone involved works on the understanding that the Core is a small set of people that are central to the business and it’s buffered up with Contract / Outsource work that is clearly only commissioned when it’s needed. In this way everyone knows what their commitment is and there’s fewer surprises. The non-Core people are typically more expensive than permanent *but* it ultimately works out to be more cost effective once you factor in the recruit/redundancy/gap costs. The team shrinks back to the Core in between projects.

Sensible studios plan for all of these things and build their business with this in mind and also build in some contingency into their costs to enable them to burn some of their profits to keep a consistent team running during the lean times. Larger studios can also mitigate this by having multiple projects and moving people between projects as the natural ebb and flow of project demands occur.

If you’re a work-for-hire/self-funded studio working for little profit who employs 100% of your staff on a permanent basis then expect redundancies at the end of every project and or the business completely failing.

As the saying goes: Failing to Plan is Planning to Fail.

As a business owner, think about this when you’re starting out as it can make a real difference to the viability of your business. As a developer, look at the business you’re working in for the signs of whether or not your likely to be around when the project finishes.

20 years of a Video Game Developer’s Career – Part 3

6 min read

I’d like to share with you my game development career experience as part of a series of posts, the 1st parttalked about my early career and I followed up with a second postthat was more about how those games were made. Let’s get back on track with the series and rejoin the fun back when the transition for PS1 to PlayStation 2 was happening.

Krisalis v2 a.k.a Teque Software

PS1 development kitsAfter a long and fruitful period of key game development the rest of the world was moving over to PlayStation 2 but we were still making games for PS1.

It wasn’t for lack of effort and respect, indeed I attended many exclusive PS1 & Saturn developer conferences across the globe. Over the years, the PS1 conferences were held in a variety of amazing locations including secret clubs and even in the middle of the top-secret high-speed ring at Millbrook Proving Grounds. Saturn conferences were always held just outside of San Jose, California where I visited later as the venue for the emerging GD Conference, which I was also fortunate to regularly attend.

I was also chosen for the exclusive 1st unveiling of the PS2 to the “cream of the development community” at a secret locationalong with short list of developers. What made this event totally cool was that it took place right before a solar eclipse gripped the UK and the event itself opened with a mock solar eclipse!

I was doing magazine interviews and I even made it onto TV once!

This is largely because we were one of the best studios in the world for doing this work and that meant that we were the ones who bigger businesses wanted to keep pushing the same work to and we were type-cast as safe PS1 developers. However this PS1 work was always going to come to an end at some point. The visual quality and scope of even the best PS1 games was rapidly becoming lack lustre when compared to what was appearing on PS2 and PC at the time that really reinforced the demise. This eventually led to some of our projects being cancelled as the PS1 nose-dived and it took our company with it.

Sadly, the studio imploded and a few of us took the mantle and tried to breathe life back into it under a new name ‘Teque Software’ where I played the role of Technical Director along side 2 other directors but it just didn’t work out and it only lasted for a few months as we still had the same reputation that we just couldn’t shake off. This was becoming worse as the other ‘new’ studios were pushing ahead on the newer platforms and we were getting further behind.

The closure of the studio came as a surprise to pretty much everyone involved but if you’ve ever ran a business in the UK you’ll appreciate the secrecy that these things have to be done under. As much as I wanted to tell people, I couldn’t as that would have been a clear breach of my responsibilities to the business as a director. I would have probably been in a lot of legal trouble if I’d have done it too. So, the closure of the studio left a bitter taste in a lot of people’s mouths and everyone scattered to find new jobs all over the UK. I had a double-whammy here because my wife also worked there too, meaning that we were both redundant on the same day.

Runecraft - levelling up and bad management.

After the end of Krisalis I quickly found a job going back to my roots as a programmer on PlayStation 2 where I worked on core animation related programming systems for a licensed platform game. Sadly, it turned out that Runecraft’s management were a bunch of crooks and totally shafted their staff but I didn’t find that out until later.

What I did get out of this period was an opportunity to connect with some talented people and also work on PlayStation 2 games and really learn about those. I fortunately was seconded to a remote part of Runecraft that was based in Leeds, 15 miles away from the head office. This meant that we had little involvement with HQ and we could just get on with things.

I met a lot of truly great people in Leeds, all of which were ex-Sony Leeds and most had worked on the likes of Wipeout / Colony Wars. Their skills were amazing and a real level above what I’d seen at Krisalis and I learned absolutely loads and I still connect with these people today.

Getting back to non-management roots was refreshing and re-filled my technical knowledge to a level where I understood the nuts & bolts of PS2 development that I’d later find to be incredibly useful.

The over promising and dodgy dealings of the management caught up with them and the company collapsed inwards. There’s only so many times you can try to deceive a publisher before they find you out and that’s inevitable.

How the Leeds studio closed was like something out of a movie. I was making my way into work and I got a call from one of the other programmers that things were kicking off. I eventually made it to the studio to find the doors locked and all of my colleagues stood outside. I was told the studio had closed and we were all redundant. Now, given we all pretty much hated the management this was both a blessing and a curse at the same time.

The door opened to the studio and a head popped out and called a name, that person was escorted to their desk where they collected their personal belongings and then escorted off the premises. This process was repeated for everyone in the studio, a slow one-by-one procession.

It didn't happen quite like thisThe mob was angry but I never got to see the end of it. Why? Because it turned out my contractual place of work was back at HQ along with 2 others from the Leeds studio. What happened next was just bizarre, one of those MPV like vehicles turned up and the 3 of us were bundled into the back along with one of the managers and we were driven back to HQ. I’m not exaggerating, this is really what happened. When we arrived we were escorted to our separate desks in the ‘programming barn’ and told to do some work on project X. To say I was surprised was an under-statement and they almost dismissed the fact that any of this had happened but you can imagine I vowed to leave ASAP. I was completely annoyed because my transport home was back at the Leeds office so when I was released I had to go back there, then back home. It’s making me angry just writing this now.

I suffered this for a few weeks while I found another job but I absolutely hated it as we treated as immigrants, we were given all the terrible jobs and we weren’t motivated to really do any work either.

What I learned was that annex/remote studios are always the 1st things to go when a company is hitting financial troubles. It’s like cutting off a gangrenous limb to save the body. All of the work can be brought back in-house and it gives the business a clear criteria to dump a load of people.

I also learned that a tight-knit group of motivated and happy developers can achieve more than the sum of their parts.

What next? Onwards and upwards

I was fortunate to be have formed strong relationships with people across the industry and I was brought in as employee #2 for the newly formed Kuju studio in Sheffield where the next phase of my career began including many of the people I’d worked with in Leeds on the emerging platforms.

This is where we’ll join the story next time…

Further Reading

Is A Game Development Career Compatible With Family Life

title: Is a game development career compatible with family life? date: 2010-08-25 13:50:18

tags: [“career”]

type: post

description: “What compromises have you made to balance your career and family?\r\n”— I’ve been following the thread over on Luke’s blog entitled ‘Goodbye, Realtime Worlds’ and I’ve commented in there when the discussion turned to the collateral effects that being made redundant has in an industry that’s so sparsely spread around the globe. The discussion isn’t about overtime in the short-term, it’s more about long-term careers in games when you’ve got other people to think about in your life.  Maybe your partner has a great job, maybe you’ve got other businesses you’re involved with, maybe you’ve got children?

It got me wondering what everyone else’s experience is like.

What compromises have you made to balance your career and family?

20 years of a Video Game Developer’s Career – Part 2

5 min read

I follow on from Part 1 of this series with some more information on how I got where I am today in the video game development community. Most of the old stuff is irrelevant but I hope it shares the need to actively plan your career to avoid some development cul-de-sacs.

Let’s continue…

I wrapped up the previous post where I’d pretty much reached a point where I recognised a need to get a grip of my own career and make some long-term plans, after all, no-one else was going to do this for me and this wasn’t going to happen overnight. Of course, this was all based on assumption that everything else would stay the same in that the way games were being made wouldn’t change too much and we all know how wrong that assumption was.

I’m not going to talk specifically about the games I’ve made as that information is available in lots of other places but but more about my career so far.

In response to some comments on the 1st part I thought I’d embellish on typical examples of how we made the games back then too. I see echos of these early development concerns being raised on small mobile platforms all of the time. Remember we’re back in the days of no network (definitely no internet), no development conferences, no degree courses, no source control, virtually no support. You did this on your own, learnt everything yourself and the only way you got stuff around was to copy it onto a floppy disk.

100% system take over

The early games were largely done on the target machine with very little debug facilities available. You made a change, compiled your code, ran it, if it crashed then it was obviously the last thing you did. It’s true to say that we didn’t have linkers either, so everything was in 1 file typically called ‘MAIN.S’ or similar, graphics were largely included within that file as a series of HEX numbers that were translated from the original files via some custom tools. A game typically took over the whole system as there wasn’t really the notion of an operating system that was efficient enough for games to use, we wanted 100% of everything available to us: memory, cpu, gpu, etc. The games didn’t share the system with anything else, everything had to be within the game.

You can imagine that these single files were pretty big and we started to push the text editors capabilities but that thankfully coincided with the advent of linkers that meant we could split our files out into sensible chunks.

It’s worth remembering that the floppy disks themselves were largely just storage, we came up with our own file-formats and file loading routines from scratch typically accessing the hardware at a low-level. For us this was an iteration of the custom tape loaders that had been the norm back on C64/Spectrum where they were necessary to speed up loading times via ‘turbo’ loads and the like. Our loaders typically involved decompression routines too as we constantly tried to improve the loading times and how much content we could fit on a disk. We also rolled our own security systems with the hope of stalling the pirates ripping off our games for at least a few hours.

Memory Management

Clever games were starting to use dynamic memory management instead of the fixed memory maps of old, these came with a massive 12-byter overhead per allocation so it was quite expensive. We naturally hit memory fragmentation problems quickly such as where we’d load a file into region ‘A’, then decompress to ‘B’ and free up ‘A’ to be re-used, i.e., typically adjacent AB. Now, if the next file you wanted to load wasn’t 100% identical to ‘A’ then you’d end up using some of it, maybe even decompressing within that space too and the whole process rapidly broke down into chaos as the largest single consecutive piece of memory dwindled into nothing.

The quickest solution to fragmented memory? Bi-directional allocation, i.e., load files from the end of memory down and then decompress from the bottom up. This also resulted in the revelation that given a little buffer space you can decompress over the top of the source file, which was mighty useful when your last file was loaded.

So, all of our game files obviously had to be compressed and this took quite a while to do on the relatively slow systems we had too. The tools we built on PC were entirely custom made and we had our own compression routines based on generally available ones, which were specialised to accomodate the specific needs of bitmaps, audio and level data.

The alternative use of compression

Our tools at the time had lots of stats, bouncing colours, meters going up and down, progression bars and all manner of bells and whistles. It was often the case that most of the content of these frontends was largely ‘fluff’ and that they gave us an excuse to do other things, I’d even say that some of our tools gave the illusion of them doing lots of work even though they’d finished! They simply waited a special keystroke command to ‘finish’ their processing. This was very handy sometimes when you just needed to be undistracted and you could just say “it’s still packing”. :)

File Editors & Remote Debug

The advent of remote debugging using SNASM dev-kits (later renamed PsyQ) brought in the use of proper compilers, linkers, debuggers and text editors. The debugger was *the* most important aspect of the whole setup and the company called SN Systems still makes the systems of choice for PS3 development.

Back then though, PC systems running DOS were the de facto standard and the ubiquitous text editor then was ‘BRIEF’, which was a revelation because it not only restored your session but also enabled you to have multiple files open in split windows! Later versions also integrated the error messages from your tools that meant you could quickly jump around your code and fix the errors quickly without referencing a separate compiler output file.

I’ll continue my career story in Part 3…