Site Search
Homepage of Otaku No Zoku
Complete Archives of Otaku No Zoku
About Otaku No Zoku
Subscribe to Otaku No Zoku
Bookmark Otaku No Zoku

Post Project Rant :

The post project area is where I rant about how screwed up some of my game projects became because somebody wasn’t doing the job for which they were hired. Either a programmer being hired in to a Lead or Senior position, or an artist who only wanted to “create fine art” and felt that the platform was restricting his artistic will.

There are no titles on the individual tales of woe. You must work out for yourselves which ones went wrong.

The following tale of woe all happened on a small project in 1999.

Art Pathway
Lead programmer was over-ruled by two other people (Producer & CEO) that it didn’t need to be perfect and that there was no time to make the pathway conducive to changing artwork. The initial in-house tools provided, when available, were primitive and buggy. Not one single established Gameboy Development tool was used on the project because the artist’s refused to work with the freely available ones, and the CEO refused to spend $1,000 to purchase commercial versions. Consequently it would take a programmer approximately 1 to 2 hours to change something as simple as a non-animated sprite.

Design Documents
Design documents were never updated by the designer/producer to reflect changes in the implementation or changes in the game design. What design document there was, was exceedingly minimal. Imagine taking the worst “code as you go” programming practises you can imagine and applying them to game design.

Inexperienced artist with no previous game specific work to his credit and no gameboy experience.

Artwork was not provided in a timely fashion. Artwork was often created with no consultation with design or programming. Artwork that was created was frequently wrong or not to spec. Examples: Background bitmaps for levels, status bar, health meter, powerup icons, pickup sprites, swarmer missiles. Non-shared palettes, incorrect sizes, sprites bitmaps that were not in sprite format. Font was incorrectly laid out, in fact, when given the font no team programmer wasn’t consulted on how it should be laid out, consequently 20 minutes had to be spent by a programmer in a graphics editor fixing the artist’s work. Inconsistent filenaming for the majority of parts. Frequently the filename on a piece of artwork would change forcing code changes that were unnecessary. Most of the time the filenames were just plain wrong. The artist is only partly to blame, there was just no checks and balances and none of the programmers had the time to teach a new artist how to work in a production environment.

Asset Management
Nobody was steering the asset management nor ensuring that all assets were available at the time that they would be required.

There were multiple producers and managers assigned over the course of the project, sometimes simultaneously. Managers were unsupportive of the project and team members. On several occassions management that was not directly associated with the project interfered with scheduling, either by over-ruling the producer & lead programmer or by directly talking to the employee and telling them what to work on with no regard to any previous planning or how it would impact future scheduling. This was a contentious issue especially at the latter part of the project.

Contract Renegotiations
The publisher/developer renegotiated the contractual obligations on more than one occassion with absolutely no regard to how it would impact the schedule.

Milestones and deliverables were frequently changed, right up to the day when they were being delivered. Deliverables were not made clear to the lead programmer and scheduling was set up in an “order of priority is the features have been sorted alpahbetically” with no regard to how one feature related to any other.

Double Duty
Lead programmer was also given the task of network administrator and tech support center for the entire company in addition to his regular duties with no provision in the schedule for these extra duties.

Inexperienced “high-level language” (Visual BASIC for applications) programmers with no game programming experience and English as a second language were provided as “suppport” programmers or placed in senior programmer roles. Management had unrealistic expectations of programmers and expected the entire project to be finished by a single person. No training or ramp up time was allowed for these new programmers and they were frequently thrown in to the midst of a crunch period, and the entire project was a crunch period.

Personnel Management
Grievances of staff, when brought to the management’s attention, were often aired publically by the company Director’s in an open hallway where all could overhear and when there was an issue with one staff member a “company memo” was often created that “shotgun blasted” everybody, creating a highly demoralising situation.

Audio No audio assets provided until late in the project. The project, as I write this, is two weeks late, and intermediate art and audio assets are still not delivered.

Feature bloat
Rather than concentrating on a core set of features that would work everything but the kitchen sink was thrown in to the game design.

Level Design
Large, expansive levels were envisioned and promised before the Lead Programmer was consulted. Lead Programmer’s comment to Designer was “You do realise that just one of these levels is larger than the largest Gameboy cartridge available?”. At that time the largest cartridge available was 2Megabytes.

Unrealistic expectations from the hardware
Lead programmer had no input in to the game design and producer was unfamiliar with the gameboy hardware and limitations.

Unrealistic Schedule
What amounted to 10 or 12 months worth of work was promised in less than 6 months. Management was assured by the lead programmer that this would not be possible but management did not pass this information on to the publisher. Even in continuous crunch it was not possible to deliver this work in less than 8 months (which as I write this is about 6 weeks away and we are on target for that), management throughout the course of the project insisted it would be delivered by a particular date. Scheduling was often done on a 7 day work week and a 12 or even sometimes, 16 hour work day through the entirety of the project.

Development Tools
No platform specific tools were available for the programmers & artists until 2 months in to the project. Management had no problem with spending lots of $$$ on artist’s computers and Photoshop but took 4 months to buy a compiler (at less cost than Photoshop). All tools used were eventually either brewed in-house, cobbled together from public domain sources (gnu make, no$gmb) or coded by the lead programmer in his “off-time” (RGBASM, XLINK, RGBFIX).

Development Kits
No official dev kit was available until 3 months in to the project. No official documentation was available until 2 months in to the project. Only one dev kit to share between 2 teams.

Feature Driven
Management insisted that the game have new features added as fast as possible with no regard given to whether they worked “as specced” or if they had bugs. This has resulted in an issue with the lead programmer being unable to “finish” because he was constantly pushed for new visual features and not allowed to finish tasks. When time was allocated to finish up open tasks they were lumped in with other, as yet, un-started tasks, so nothing ever really got finished. Frequently features were rushed and not closed out so that they now remain issues and reflect poorly on the project. No thought was given by producers/designers to how features should work or how they would impact the game. When implementing features often a time was demanded of how long it would take, but a lot of the time, problem solving is not a linear activity, it is impossible to sit down and say “the time to solve this problem will take n number of hours” and then you work on that problem and implementation to the exclusion of everything else, vis. destructable buildings. There were many things that impacted how destructable buildings worked, and they actually took about 6 weeks to tweak and get right and implement to the point where everyone was happy with them, but they actually only took about 8 days of real work. There were many problems that had to be solved and not all solutions that were found actually worked out, but management frequently became frustrated because “destructable buildings still aren’t working”. Destructable buildings were a solution that evolved and demands from the producer to “sit there and finish them” would have meant that everything else was put on hold, for large problems that need to be broken down piece by piece this is not possible.

No incremental testing and review process was available for the project. It was an attitude of “just implement all the features and then we’ll find out what’s broken or doesn’t work later on”. No QA was available at any point during the project until the game was a beta candidate.

Project Specific Tools
No time was placed in the schedule for project specific tools to be created. When extra programmers were added they created new tools that worked at cross-purposes to the original tool set, increasing the designer’s workload and duplicating effort on the part of the programmers.

the only budget allocated to the project was for personnel. No budget was made available for project specific expenses.

Designers were placed on the project that had no gameboy specific experience. This happened not once, but twice. Just as with the artists and programmers.

Lead programmer
Lead programmer was placed in “crunch time” from day 1, working 7 days a week, 12 to 18 hours per day, for the first six months until morale issues and mental exhaustion forced him to “slow down and lose productivity”. The lead programmer was not consulted on many issues and when he was, his judgement was frequently questioned or over-ruled. Outside “consultants” were used to comment and critique the project and lead programmer. But nobody commented on the management style of the project itself. Frequently the lead programmer was placed in a non-lead role.

Project Management
because resources were frequently allocated to other projects in the company and there were multiple managers and levels of management a ten minute feature implementation turned in to a two day “discussion”. There was no centralised management that oversaw the entire project.

“Visual” Management Style
management insisted that they be able to see something on-screen, and as soon as it was on-screen then it was “closed out” and announced finished by them. This happened all too frequently especially during the very early stages of development when features were just being crammed in “to have sprites on the screen”.

Resource Reallocation
Programmers, artists and designers were frequently re-assigned to other projects in the company. What should have taken one full-time lead programmer and one part-time programmer 10 months to complete took one full-time lead programmer and three other programmers who were frequently pulled to other projects for days or weeks at a time 10 months to complete.

Liked This Post?

Subscribe to the RSS feed or follow me on Twitter to stay up to date!