Arcade graphics programmer interviews?

[Pixel_Outlaw]

So maybe this would be a better fit for a different forum but I think (maybe?) there are people here who can give me some insight or point me to articles.

If you crack open MAME and view a game pallet at different times you see a lot of colors being swapped in and out of their available 256 on screen color set.
So we know that artists had to have some limit on the colors they chose to be in the palette but they also had to know what tiles/sprites the programmers were going to put in the game at any time.
It would seem that for the artists their on screen color restriction was constantly changing and highly dependant on the level designers.

I'd be interested in some of the communication they had to work around this GIANT mess between programmer, level designer, and sprite artist.
I know we've all read articles perhaps somebody here has come across an interview showing the approach to this 3 way deadlock of game making interest.
A very strange question I suppose. I'm just doing some pixel art and want to limit myself to something very traditional looking while going the extra mile and understanding traditional burdens placed on pixel artists of the golden age of arcades.

Has anyone come across much to shed insight on how teams worked together in the graphics area?

[GaijinPunch]

My first guess is very general, but I think it would fit a lot: there was a lot of team overlap. We know that back in the day, some people had to wear many hats. Uemura of Toaplan fame did music and programming. I started a translation like 8 years ago of an interview with Papara Kaito (Night Striker, Camel Try) and one day may pick it back up (no joke I brought it along with me on my Xmas travels) who did hardware and software. My guess is that even if there was a traditional 3-team approach to any given game, each team had to know hardware limitations, and couldn't just do whatever the fuck they wanted.

[trap15]

It's just coordination and proper communication. Stage designer says "give me these types of enemies", artist comes up with a palette setup and graphics tiles that will all work within the limits while delivering what the stage designer wants, and the programmer integrates the palettes and tiles as used. Sometimes for squeezing extra juice the programmer goes through extra effort to "break" the system limits by swapping data mid-level, but this requires good stage design and asset coordination.

You'll never see anything like this made where teams act completely separate and just throw their work over the wall.

[MintyTheCat]

Well, in those days - as today, it was really a matter of coordinating project work and having the developers in place who were suitably clued up on the target's specs and that includes sprite sizes, memory and types of memory available and the available palette and sometimes the video mode in use and any other factors.

Given that these guys back in the old days shared small, cramped office spaces for months on end you would expect there to be some form of coordination in place - we can assume this because the projects were delivered and we all got to play them. The teams that did not do this would have failed and teams fail for many reasons. If the project manager felt that something was not right or missing they would correct that issue to ensure that the game was delivered to budget and time.

Not a great deal has changed over that time and you still need people who could do the work then as you would now with perhaps less skill stratification back then - many musicians also had a hand in the game's audio driver and code - not sure the average professional videogame musician would have that same level of programming experience now but it can also be said that things were generally simpler back then and more immediate and it makes sense if you have a limited budget to hire someone for the music who can also handle the game code. It also makes good sense to hire a music creative who understands the realities of working with a resource-constrained target that a 'civilian' might not immediately grasp.

[Pixel_Outlaw]

I think you're probably right.
Smaller teams with people having multiple roles.

Can you imagine the discord from a company the size of Ubisoft all trying to get 300 artists communication with 300 programmers over 256 indexed colors?
Each artist probably responsible for a group of 16x16 pixels requiring management signoff and some SVN checkout system.
(Okay okay, they'd just build custom tools and leave the art to a handful of people I admit)

I suppose limitations were similar for any console artist too, not just arcade artists.

I guess if I were to do it, I would give the artist tools to just design a stage and when the palette is full (minus the reserved HUD colors) they know they need to rework their sprites.
Gets a bit more complex with 2 or 3 artists making sprites at once.
I wonder to what extent in house art tools were used in the early and mid 90's that let artists know when they hit the color limit of their pallets...


I came up short on articles myself after quite a bit of searching.

[MintyTheCat]

pixel_outlaw: you are speaking more of company policy that you would find at IBM, Siemens, etc. They have policies and everyone just gets on with it.

What you tend to find is that larger companies lack the ability to change quickly - to adapt. I remember working for one company who had an entire department devoted to simply one build-system and it was not 'possible' (it was ) to alter the build-system for any reason without passing it by them first - speaks of culture more than anything and the more effective teams are able to run with it, make changes and correct issues a lot faster. This is another reason I like a certain size of team - it just gets too be scarily slow and you spend eons in endless meetings -- which is fine if you are some kind of lawyer but not really what most developers want

A good idea would be to read some books on software project management: there is an optimum size pretty much and after that you tend to spend more effort and time 'policing' the effort, dealing with communication and bring actions together than anything. It is akin to being the village elder with a few families and having a system of governance in place then comparing what you can achieve and how quickly you can bring it into action in that sense and then if you were running something like the United-Nations or some government with a few million citizens.

These days even most large companies split their developers and project people into much smaller groups and it is not like it was in the 1960 or 70s - even IBM had to agree that it was not working

These guys in those days were pioneers, they were often making it up as they went along with it and they put the hours in and had to handle situations but it would have taught them a great deal and informed their judgement to no end.