An interview with Ronald Pieket Weeserik
It is my absolute privilege to introduce a true legend of Amiga gaming: Ronald Pieket Weeserik. All his games look incredible, silky smooth and plenty of action. Most Amiga owners will have played SWIV, probably the greatest vertical shooter ever written on the mighty Amiga!
- Silkworm - Code
- Ninja Warriors - Code and music
- St Dragon - Some sound effects
- SWIV - Code and design
- Rodland - Code and music
- Q-Bic - Code, graphics, music and sound
How old were you when you got your first computer and what was it?
The first computer that I owned for myself was a ZX Spectrum, in 1983, when I was 22 years old. But 1979 when I was 18, my best friend Nico's father got an Apple ][, which Nico and I spent a lot of time programming. Nico went on to study Computer Science at the University of Utrecht, and I became a games programmer. But that Apple ][ got the ball rolling for us both.
What programming languages did you learn and in what order?
Well let's see. I first learned BASIC on the Apple ][. Shortly thereafter I learned the 6502 assembly language, also for the Apple. On the Spectrum, first BASIC, and then Z80 assembler. More Z80 for the MSX computers. Then in an attempt to get a "real" programming job, I became a certified COBOL programmer. Then 68000 assembly language for the Amiga. All the Amiga and ST games at The Sales Curve were done in assembly, but I learned a bit of C for writing tools that ran on the PC. That was the first time I could program a computer without first learning the hardware inside and out. Then 65816 assembly for the SNES. Back to C for the Sega Saturn and Sony Playstation. My first project in C++ was for the Sega Dreamcast. Been using C++ ever since: PS2, Xbox, PS3, Xbox 360. I did a cross platform project a while ago, written in Java. Right now I'm learning Objective-C for Mac OS X and iOS.
How did you meet the other members of Random Access/The Sales Curve?
In 1986, I wrote several MSX games for Aakcosoft in the Netherlands. When that company closed its internal development in 1987, there were no other game developers in the country. The unemployment bureau let me retrain as a COBOL programmer, to help me develop a career in corporate software. But as I was doing that, I hatched a plan, got an Amiga, the programming manuals, and spent several months developing a simple game on it. In the summer of 1988 I packed the Amiga, as well as my MSX computer, and several floppies with my games, and stepped on the ferry to England, to visit a computer games trade show. It must have been the first ECTS. Anyway I talked to several developers there, got myself some interviews, and The Sales Curve hired me. Sold everything I owned in Holland, except for my two suitcases with clothes, and moved to London. Dan and John had only been with the company for a few months when I joined.
What development system did you use for your Amiga games?
I believe we started out with DevPac and CygnusEd, which both ran on the Amiga itself. This involved writing the source code, running the assembler, and running the game on the same machine. We didn't even get hard drives until SWIV. At some point we switched to Snasm and Brief, which allowed us to use a PC for writing the software, running the game on an Amiga remotely. I believe we briefly used another development system, similar in many ways to Snasm, but I remember it was quite unreliable.
Of all the Amiga games you worked on, which was your favourite?
That's impossible to answer. Which child is your favorite?
How did you acquire the rights to convert the Jaleco coin-ops?
Ah, there is a story there. The Sales Curve was not originally going to be a software developer. I believe the original business model, as envisioned by Jane Cavanagh, had been to represent foreign software developers, and hook them up with UK publishers. In any case, one of the companies Jane was doing business with went bankrupt, and in the bankruptcy procedure, TSC ended up with several arcade game licenses, including Silkworm and The Ninja Warriors. Jane decided to put a team together to develop them. The rest, as the saying goes, is history.
Did you ever see arcade coin-ops that you enjoyed get an absolutely dire conversion and wished you could have converted them yourself? (Personally I would have loved to see what Sales Curve/Storm would have done with Street Fighter 2 instead of the game US Gold released!)
Gauntlet! The problem was that it used a lot of hardware sprites, and a lot of color, and a (for that time) high resolution screen. No home platform had the muscle to handle it. Also, I was a big fan of Q*bert at the time, and never saw a home version that did it justice. So I did it myself. Twice. Once on the MSX (Fuzzball), and once on the Amiga (Qbic).
You seemed to take immense pride in writing quality games. Are you by chance a bit of a perfectionist?
Yes and no. I think it is more about knowing what the game needs, but also what it doesn't need. Pick your battles. If you spend too much time perfecting one aspect of the game, other aspects may suffer. You have to know what the players will see, and what they won't notice. It's all about getting the most noticeable bang for the time spent buck.
Did you have much of a chance to look at what other programmers were doing at the time? If so, which ones impressed you?
I was not so much aware of individual programmers. But teams, definitely. The Bitmap Brothers come to mind. They were the guys to beat. I have good memories of playing Xenon and Magic Pockets. But perhaps my most favorite game of that time was Lemmings by DMA Design. Brilliant game design, and very well executed. How much cuteness can you cram into an 8x8 sprite?!
There is fierce debate on the Amiga forums about another famous vertical scroller - Xenon 2. Had you played it back in the day (1989) and if so, what did you think of it?
Absolutely. I loved it, and it was a great source of inspiration for SWIV. As was Hybris.
Did you feel any teams (Tiertex, Dinamic etc) were just happy churning out garbage when Storm were trying to create superb games?
It was a crowded market. I'm sure the Tiertex programmers were not allowed as much time and resources as we were. And Mercs wasn't at all bad!
In the Final Fight startup-sequence, Richard Aplin wrote the following:
Any road up, on this game I'm reasonably pleased with the interrupt-driven
disk loader; everyone else did it ages ago - so did I, but that sort of
loading is not really suitable for most types of games: you need dynamic
memory-allocation and multi-tasking uncrunch routines for a start, and then
you run into all sorts of problems with ram fragmentation, and eventually
you end up spending more time sorting out the problems caused by the system
than it solves, but I thought I might as well use it in Final Fight, just
so that Ronald Van Thingy at the Sales Curve would shut up! (Sorry Ronald!)
Was that a tongue-in-cheek reference? Did you know Richard Aplin well? Any personal competition or anything like that?
Oh gosh, I guess he does refer to me. I did not know him well. Nothing personal, but we all tried to make our games better than the rest.
Do you have any idea about sales figures for your games? Which was the most successful, and least successful?
I have no idea about the sales figures. SWIV was a big hit, as was Silkworm. I'm not sure that Rodland made all that much of an impact.
Of all your games, which was the quickest to write?
All my games? There are more than twenty! But I wrote the first seven games in the first two years of my career - and that included in most cases doing the game design, the graphics, the sound effects and music. Out of all of them, I think the quickest was Police Academy II for MSX. It was written in about six weeks. (And it shows - ouch!) Out of all my Amiga titles, the quickest was Qbic. Out of all my commercial Amiga titles, Rodland.
How did you decide who in the team would be the main person converting each game? Or did you work closely with John on most of them anyway?
John Croudy was the Atari ST expert. I worked primarily on the Amiga. But we worked quite closely together, and most of the code was written to work on both platforms.
Silkworm and The Ninja Warriors were programmed by John and myself in close collaboration. Then came SWIV, and that was really Ned's and my idea, so we got to do it. If I remember correctly, John did Saint Dragon while Ned and I were busy with SWIV. Although he must have joined us on the project later. (Memory is fuzzy) The final call on who did what was always Jane's.
For a typical game, would you calculate how much room you were going to allocate for code, graphics and sound before you began and everyone had to fit into their allocation, or was it far more flexible than that? I imagine some poor sound guy at the end of the memory food-chain being told to reduce his 100Kb tune to 50Kb etc!
Well, the "everyone" you mention was only Ned and myself. There was never a sound guy. I did all the sound effects myself. It was my favorite part! The music for Silkworm and SWIV was bought as tracker modules, and since they played only on the title screen, the size didn't really matter. When the game starts, the music data is removed before the game data is loaded. The music score for The Ninja Warriors and Rodland came from the arcade machine, but I did all the programming and sampling. SWIV in particular, and to some extent Silkworm used a form of software synthesis, so their sound memory requirements were modest.
The memory map for each game was quite simple. The largest chunks of memory were known well ahead of time. The frame buffer size depended on the scrolling technique. That was by far the largest chunk that could not be used for bitmaps. And I had a multitasking system that relied on switching the stack pointer around, so I needed memory for several stacks. But most of the rest went to graphics data. I think Ned understood that there was very little room for negotiation.
Silkworm was one of the first games I saw on the Amiga and couldn't believe how silky smooth it was, and better than the arcade!
You really think so? Amiga Silkworm held up quite well among its contemporary Amiga games, but that says something about the state of Amiga games at the time. Arcade Silkworm on the other hand faced some really tough competition (R-Type!), and didn't do particularly well.
How long did you have to write this one?
I will have to reconstruct the sequence of events, let me think. It was my first project at The Sales Curve, and I started there in October of 1988. The Ninja Warriors came out in 1989, and we worked on that during the summer. So Silkworm must have come out in the spring of 1989. So from October to spring - somewhere around five months or so.
Was the Amiga the lead version or were both written together?
The Amiga and Atari ST versions were written at the same time.
Silkworm features full 50 frames per second and parallax scrolling! Correct me if I'm wrong but I suspect the way you did the parallax was the main area scrolled at 1 pixel every 2 frames, the copper scrolls the game section at the bottom of the screen 1 pixel per frame, and to achieve the parallax effect you are only drawing the small hills (and any other bits that stick on top of the road) onto the screen as if they are sprites? So you only have to redraw the foreground scrolling objects every frame along with player and bullets?
You are quite right. You will notice that, as the game progresses, I need more software sprites for gameplay, and consequently the foreground scrolling objects get fewer and farther between.
The game appears to be multiplexing sprites for all the bullets, including different bullet graphics. Another guess, you put all bullets for the screen into a list, sort them by increasing y co-ordinate then x co-ordinate, and re-use the sprites in a loop?
That is correct. All hardware sprites for a frame are collected, sorted by Y (but not X) and assigned to the available sprite channels in a rotating sequence.
If that is the case, is there ever a possibility that a sprite will vanish or did you somehow make sure you'd never have more than the maximum on a scanline?
It is more than possible: it happens all the time! Especially in two player mode, with all guns powered up, and under heavy attack. But you don't notice it much, because I rotated the sprite assignments, so that every next frame, a different sprite would be dropped. The result was that when there are more than the maximum number of sprites on a line, they would only flicker, not disappear for any length of time. This is a trick that I learned while programming MSX games, which had only 4 hardware sprites.
How does the game synchronise moving the sprites around?
I'm digging around in memories from twenty years ago, so I can't guarantee accuracy. But I think this is what is going on. The sprite hardware on the Amiga has some serious limitations. If I recall correctly, to reuse a sprite channel multiple times, using the DMA hardware, the sprite position information and the bitmap must be interleaved. So the position information will be followed by the bitmap, followed by another position and another bitmap, and so on. This requires that you to create multiple copies of the bitmap in memory. Every frame, you would end up copying the sprite bitmap as many times as there are hardware sprites on the screen.
Did the various people converting each version talk to one another about how the game would work on each system or was the hardware so different that there really wasn't much in the way of code and ideas that could be shared?
The 8-bit versions were developed independently from the 16-bit versions.
Did you ever get feedback from Tecmo about your conversion? Most people seem to think the Amiga version betters the arcade!
We never had any direct contact with Tecmo. Remember that Tecmo was a Japanese company, and the Amiga was practically unknown in Japan. I imagine they didn't care much about the conversion.
It looks like you converted almost everything from the game perfectly - even the hexadecimal countdown of how many enemies before the next goosecopter! Did you consider changing that to decimal?
Of course not. We wanted to be faithful to the original.
The Atari ST version appears to run at about half the speed of the Amiga version, maybe less. Did you do any work on the Atari ST version? (It must be difficult without hardware scrolling and sprites as they were used so effectively on the Amiga!)
The Atari ST had the same CPU power, but none of the nifty blitter and copper chips that the Amiga had. All the scrolling and sprite drawing had to be done with the CPU. Full screen scrolling, in particular, is quite a heavy task for the processor. All the credit for the ST version goes to John Croudy. He made the miracle happen.
Did you ever consider adding different bosses rather than just cycling through the giant helicopter and tank? Or was the job simply to do an accurate port and not better the original by too much? :-)
We did not really have much time to add new stuff. We tried to get as close as we could to the original, and that was hard enough. And on top of that, this was my first real Amiga project - I really was learning as I was programming. I'm quite proud that we got most of the arcade game in.
The Ninja Warriors
The arcade coin-op display is 3 normal screens wide. Was it an obvious decision to make a full width game with a very short height to keep the aspect ratio similar? Or did you contemplate making it a lot taller?
If we had changed the aspect ratio of the screen, we would have changed the game play. If I remember correctly, the Amiga version has an aspect equivalent to two screens side by side. The arcade has three, so it was a compromise. But just as importantly, the reduced screen height helped performance. Smaller sprites to draw, and the 32-color mode makes the CPU run slower, so a shorter screen reduces the impact.
How did Ned feel about having all those extra colours compared to Silkworm?
The graphics for Silkworm were all recreated by Ned, merely by watching the arcade machine. But Taito gave us the graphics files for The Ninja Warriors. I wrote a program to reduce the size and the number of colors. Then Ned fixed them up where needed. But compared to Silkworm, his involvement was much reduced.
Ninja Warriors doesn't seem to be using sprites at all. Was that due to the 32 colour palette not repeating like Silkworm/SWIV? I thought maybe the shurikens would have been done with sprites.
We couldn't use hardware sprites because of the way they share colors with the 32-color screen. And in any case, we did not need as many projectiles as in Silkworm, so drawing a few extra small software sprites was not a big deal.
The arcade features a layer of parallax scrolling. Did you intend do add that in or it didn't add anything to the gameplay so was never going to be included?
We used hardware scrolling. Parallax scrolling in Silkworm was achieved by a copper driven screen split. But parallax scrolling of the kind that was used in The Ninja Warriors arcade machine would have had to be done by the blitter. We didn't think it was worth the performance cost.
Was there any fancy mapping tool used in the game or was it simple 16x16 (or whatever) blocks?
It was a simple tiled background, converted from the arcade machine data.
The Amiga version seems incredibly difficult compared to the C64 version, especially if you accidentally fire ninja stars instead of the normal attack and end up fighting the end of level guardians without a decent weapon! Were you guys able to play through the entire game easily?
Yeah. But we're hard core! :)
As far as the music was concerned, did it have to be re-created from scratch by listening to it or was the music data able to be lifted from the original?
Taito provided us with the sheet music and some of the instrument samples. I recreated the wave data for missing instrument sounds with a simple FM synthesizer that I wrote for the Amiga. The same one, by the way, that I used for Saint Dragon, Rodland, and Qbic. I converted the sheet music to numbers, by hand. The music driver uses dynamic voice allocation to give the illusion (perhaps not entirely successfully) of more than 4 channels.
By the way I was, and still am, in awe of the Zuntata score. Daddy Mulk is an awesome tune! I love Japanese techno pop.
Do you recall how long did the music took you?
I don't quite remember. Probably a couple of weeks.
Was the game a lot simpler to write than Silkworm due to your knowledge of the Amiga at that stage and the sprites, smaller display area etc?
The programming was a lot more sophisticated. The Ninja Warriors uses a preemptive multitasking system and dynamic memory allocation, which were new to us. In hindsight, it was probably a little over-engineered.
Were there any difficulties creating the game?
We didn't have much time for it! The biggest difficulty was that we entered into a crunch period pretty much from the start.
Presumably since it was pre-SWIV, this was still developed without a hard drive?
I think we had hard drives by that time. But we were still developing on the Amiga itself, no PC.
When converting a game like this, is there a point where you just become sick of it and want it finished compared with an original game like SWIV where you can develop new things as you go along?
We were talking about SWIV throughout development of The Ninja Warriors. And yeah, we were looking forward to starting that.
Did you ever download cracked versions to see how the hackers defeated the copy-protection?
No. But let me tell you a little story. The Ninja Warriors had so much graphics data, that even using compression and a custom disk format, we needed two floppies. It also had several layers of protection. A couple of days after release, not only was it cracked and all over the bulletin boards, but it was now in a standard disk format, and they had fit it on one floppy. The hackers had actually improved the program!
Any other interesting things you recall about the development?
We ran out of room in the Sales Curve offices. Jane had just bought a new home, but not moved in yet. She set us up with our computers in her unfinished living room!
The musician information is missing from the credits screen in St Dragon. Do you remember who wrote the music and sound effects?
I'm not sure who did the music for Saint Dragon. But that rather thin sounding lead voice is definitely from my Amiga FM synth. I'm reluctant to take the credit as "musician" for any game if I did not compose the music. I did not compose music for The Ninja Warriors and Rodland, but I provided some of the instrument sounds, wrote the music driver, and converted the sheet music into lists of numbers. But Qbic is mine, music and all.
Update 31/05/2012: John Croudy confirmed that he wrote the music for St Dragon. You can read all about it in his interview!
Who came up with the name SWIV and at what point did you settle on the name? And what does it mean? (The internet varies between Silkworm IV, Silkworm In Vertical, Special Weapons Interdiction Vehicles). What did the actual team call it?
The actual team called it SWIV! We were going to develop a sequel to Silkworm. I proposed to call it Silkworm 4, instead of Silkworm 2, only because I thought it might be a little more unexpected. Create a little bit of intrigue. But soon it became clear that we could not legally use the name Silkworm. Internally, we had already nicknamed the project SWIV. I believe Dan Marchant started that trend. He also came up with several alternative origins of the name, such as you mentioned, and more. He made sure that magazines got conflicting explanations. A great move because it got people intrigued and talking - back then and apparently to this day.
Was the Amiga version of SWIV the lead version?
Yes, very much so.
How much design went into the game before you started coding, or was it constantly developing during the natural life cycle of the game?
There was very little formal game design. I first developed the map editor, and the game grew from there.
I thought I'd have a fresh look at the game so fired it up in WinUAE and looked at the copperlist. I couldn't believe my eyes that the game is running in 4 bitplane mode! Ned Langman did incredible work with 16 colours! (+ sprites for bullets)
Ned's genius usage of such limited resources was very much key to the success of this game, and others that we made during this period.
Were 16 colours chosen so it could be easily ported to the Atari ST? Or was that all Ned wanted/needed to create an awesome atmosphere?
No, the choice to use only four bitplanes was made for memory and performance reasons. If I recall correctly, the Amiga's CPU would run slower if more than four bitplanes were used. And of course the use of a five bitplane frame buffer takes a lot more memory. And I just remembered another reason. If you use a 32 color screen, 12 out of those 32 colors are used by the hardware sprites! And due to the way I wanted to multiplex the sprites, those 12 colors had to be four repetitions of the same three colors: white, gray, and pulsing yellow/red. So in 32 color mode instead of 16, we could have used only four additional colors for the backgrounds, plus white, gray and pulsing yellow/red, or I would have had to sacrifice the hardware sprites. And as you can see, we got a lot of mileage out of those 8 sprite channels.
But if you look closer, you will see that there are a lot more that sixteen colors in the game. The four bitplane frame buffer uses hardware scrolling. It is not redrawn. There is a fifth bitplane, that is enabled for only eight scan lines, to display the non-scrolling score and status line.
But by far the most important enhancement was the fact that the copper was programmed to switch the colors in the palette, on any line in the map. So the top and bottom of the screen could have completely different palettes. This allowed us seamless transitions between areas with different colors. So we have the desert with browns and yellows, the sea with shades of blue, grassland with greens, lava with reds, and so on. Ned made very clever use of this.
How long did the game take to write?
We started immediately after The Ninja Warriors came out. That was late 1989, and SWIV came out in early 1991. So it must have been about a year and a half. That was a long development cycle in those days!
The game runs at 25fps. Was that a deliberate design from the start or there was too much action happening to make it 50fps?
We wanted mayhem. We chose gameplay over frame rate.
There are occasional points in the game where it slows down (especially the huge number of stealth fighters that fly over once the first big baddy is destroyed, it looks like the game drops to about 16 or 12fps). Did you think it'd be better to slow down but have a huge attack wave than smaller characters or less fighters?
I've always thought of the attack wave design as a musical composition: there is a rhythm to it, fast parts, slow parts, build up to a crescendo, then calm again. As I said we tried not to compromise gameplay for frame rate. I think players in general are forgiving if a frame rate drop occurs during a "holy cow look at this" moment.
Is the game using the copper-split method where partway down the screen (which changes depending on the scroll) it is effectively "reset" to be the top so you only need one screen for the buffer? Or is it redrawing the entire screen every frame?
The screen is not redrawn. It is made to scroll by the copper. The copper was also used to make the frame buffer wrap around, like you form a sheet of paper into a cylinder. So what is shown at the top of the screen could be the bottom of the frame buffer.
The copper was also used to make better use of the hardware sprites, and (as I mentioned above) to modify the palette throughout the map.
Whose idea was the load-while-you-play system? How long did that take to perfect?
I believe it was my idea. I first developed the technique for Silkworm. The final boss encounter followed the last level immediately, but used a different set of graphics. The boss graphics did not fit in memory with the rest of the level, so I decided to load them from disk, as you approach the final screen. Then I used the idea extensively for The Ninja Warriors. By the time I used it for SWIV, I had done it twice before, and it was almost routine.
How does it work? (I am guessing the game is running mostly from the vertical blank interrupt and there is a main loop doing nothing but waiting for specific points, loading data from the disk and decompressing it over a safe area of memory for the next batch of baddies and tiles?)
That is exactly right.
What map editor did you use or was it a custom written one?
Oh boy. The map editor was a custom tool, and a monster of a project in its own right. For one thing the map is not tile based. It is built up out of sprites. It allowed Ned to place all background elements on pixel positions, and overlap them in any way he wanted. The editor also allowed Ned to place the copper-driven palette changes that I mentioned. And of course it let him place the enemies.
The map for the game is huge! Who created the map? Was a common map used for all versions of the game (ie. 8 bit and 16 bit) with different graphics or different tile sizes meant this wasn't possible?
Ned Langman made the map, with endless patience and precision. Correct me if I'm wrong, but I believe it was the first game to use one continuous map. The maps for the other versions are completely different.
How did you store the attack patterns data?
Ned had to place markers in the map to trigger enemy waves, and position bosses. Movement patterns and behavior were programmed in code.
Was the game fun to write? (It seems most Amiga users remember this game fondly so I hope it wasn't a chore!)
Yes and no. We were genuinely excited to be working on something this cool. After two arcade conversions (Silkworm, The Ninja Warriors), it was the first time that this team (Ned Langman, John Croudy, Dan Marchant, and myself) were allowed to make it all up. The sky was the limit. Well, the sky and blitter performance.
On the other hand, there were a lot of all-nighters, cancelled vacations, missed deadlines, lonely spouses, and trying to convince our boss that we could really pull this off, if we could just get a little more time.
Were there any impressive technical tricks in the game that you are especially proud of?
Oh gosh, quite a few. The size of the map, and all the tricks we used to bring variation in it. The sprite based map. The dynamic disk access.
But let me mention something that not many people have noticed: SWIV uses a software synthesizer. There were several samples, but many of the sound effects are synthesized in real time. Sound synthesis was (and is) a hobby of mine.
The player bullets seem to be created with sprites, and 2 separate sprites for a 'double bullet'. Was this a deliberate design idea so one of the shots could hit an enemy and the other one continues up the screen to hit another target?
Hmm, I'm not sure why we did that. If there is room in the sprite, it would be smarter to have a double bullet graphic. If you want one bullet to continue after the other hits a target, you can always switch it to a single bullet graphic. It's odd. But I'm sure there was a reason for it at the time.
You must have heavily re-used the 8 sprites all over the screen for all the bullets. Is the game repositioning them on the fly as it's drawing the screen?
The copper repositions the sprites dynamically. I don't think I used the control words.
Harry (one of the WHDLoad team that hard drive installs games) noticed that the score panel at the top used some trick that doesn't work on AGA machines and that part of the game had to be re-coded. Can you remember how the score part was done?
It uses a non-scrolling fifth bitplane, and a trick to make it mask out the other four bitplanes, so it looks like it sits on top. The fifth biplane is only enabled for those few scan lines. AGA machines did not exist yet.
How did the score panel mask work? The only obvious way I can think of is to 'OR' the score graphics onto bitplanes 1-4 and have 5 enabled? If you play the game under emulation and switch to AGA mode all the status panel flashes reds, oranges and yellows - the colour palette entries 16-31 for the bullets. So it looks like the trick to make that plane sit on top doesn't like AGA machines.
The 'OR' method that you describe would require the line to be erased and redrawn every frame, at least on the four scrolling bitplanes. Two expensive operations! No, the obvious way to do it would be to set palette entries 16-31 all to the same color. But that would have worked without trouble on the AGA chip set, so I must have done something else - I can't remember. Your knowledge of the Amiga hardware is a lot fresher than mine. I haven't touched the platform for two decades.
Nearing the end of the development you must have known you had a big hit game on your hands. At what stage of things did copy protection come into play? Who chose the protection system (Rob Northen copylock) and did you implement it?
Rob Northen didn't have much competition at the time. We really did not spend much time thinking about it, or installing it.
Did you ever try and disassemble or crack the copylock yourself to see how difficult it would be for hackers?
I don't remember doing that.
Do you have any idea how much a copylock cost for a game?
I was never involved in purchases or licensing deals.
Did you read the SWIV reviews at the time? Were any of those unfair/too low? (I personally think anything under 90% is a travesty!)
Yes, of course I have read them!
But let me tell you, as cool as it was (and helpful for my career) to have had a hit at that time, what really strikes me is how fondly people remember SWIV, even now, twenty years later. That blows me away. So - thank you!
Do you still have the source for this game (or any of your games?)
No. Lost in the mists of time.
Another amazing 16 colour game from Ned Langman! His palette looks brighter than the arcade, another case of bettering the original! Would Ned always be a little ahead with the graphics or would you have to use placeholder graphics until he was able to make them all?
We used placeholder graphics. But it didn't take him long. We got the original graphics data from Jaleco. Ned had to do a lot of work to make it all fit, and make it look good with the limited palette, but after so many Amiga/ST titles, he was so experienced that he could do that very quickly.
Who chose the colour palette - programmer or artist or a combo?
That was all Ned. He's the man with the pixels.
There seems to be 3 different Amiga versions of the game, v1.30, 1.30s and 1.32. Do you have any idea what the differences are between the 3 versions?
I didn't know there were other versions!
Who came up with the (brilliant) idea that the score panel for Rodland should be completely composed of sprites? (I assume a smaller display window area, so lots of extra DMA time etc!)
I'm pretty sure that was me. Thanks. It was my fourth and last full size Amiga project, and by that time I knew the platform quite well. Among other things this trick allowed me to scroll the playing field, and keep the panel static. Essentially a vertical screen split.
How much help did you get from the coin-op people Jaleco with the game?
They gave us the original graphics files, and the music score. Ned converted the graphics, and I converted the music. We did not have any contact with Jaleco other than that. We did not get any code.
Did someone have to play through the arcade and draw/photograph the levels to duplicate them including start positions for the monsters? Or you had maps?
Yes, I believe the levels were duplicated by observing the arcade machine. We had one in the office, and on free play of course. It's not a big game, simple maps, so doing the maps this way was not a big deal.
Did you know at the time that the coin-op has a special "extra" set of 32 levels that could be accessed with a certain set of moves before depositing a coin? (Apparently also made available if you completed the game). If you didn't know this but had at the time, would those extra 32 levels have been able to be included in the Amiga version or there was no time?
Hmm, I recall seeing the sprites. They were included in the data we got from Jaleco. And I recall wondering what they were for. Now I know!
Map question again - this one surely used 16x16 tiles? What map program was used this time?
Yes the maps were tile based. As for the map editor - I have to get back to you on that. I will ask Ned!
Were baddies simply placed on the map and their own logic would make them chase the player hence levels could be constructed quite quickly?
All the behavior of the baddies was done in code. They just needed a starting position.
You are credited with samples in the game Final Blow. Can you tell me what you did on the game?
I did not work on the Final Blow. It is possible that they used sound code or samples from one of my previous games. I really don't know.
Q-Bic looked like such a slick well presented game that it could have easily been released as a commercial title. Was it ever intended to be a commercial game or you always intended it to be charityware? Did you see if Storm would publish it?
Thanks. But I think it was a little bit too small and simple to be commercial. I made it because I loved the arcade machine so much. I think Q*bert was a fun and elegantly designed game.
How many levels are in the game? Is there an end screen? Or does it wrap around at some point?
I don't remember how many levels there are. But it definitely ends up in a loop - just like the arcade machine.
Was it written in your spare time?
How long did Q-Bic take to write?
Not long. I knew the Amiga like the back of my hand by that time, and the game did not stretch the Amiga's capabilities. So I kept the code simple, and concentrated on making the graphics and sounds as polished as I could. It's the last game I ever made all by myself. I did the graphics, sound effects, I composed the music, too. And that's my voice muttering when the side-walkers appear.
The readme for the game says that it takes 400kb of memory or so. That seems a very large amount for a "simple" game considering something like Silkworm or SWIV uses only 100kb or so more and is full of attack waves and scrolling backgrounds etc! Are there extra presentation screens I haven't seen or did you use the extra memory for much clearer sound effects or something?
I used all available memory to make it pretty and slick, because I could. By the way did you notice that the default high score table has cubist painters on it? Geek humor.
How did this game end up on CU Amiga's coverdisk?
I'm not sure. I guess they grabbed it from the bulletin boards. I made the game free for everyone, and that included CU Amiga.
Regarding that particular coverdisk: "The ELSPA didn't take too kindly to CU Amiga giving away Shaun Southern's conversion of the classic 8-bit blaster POD, and promptly banned them from featuring any more such conversions on their coverdisks! The September 1992 issue also featured the superb Q-Bert clone Q-Bic on the same disk as POD." Did you know about this?
Well, I like the use of the word "superb"! I know nothing about the POD controversy.
Is the music player on St Dragon, Rodland and QBic identical? Would QBic have the latest replayer code that would be backwards compatible with all of them?
No, the music code and the data format were thoroughly revised between those titles.
Q-Bic appears to be your final Amiga game (sob!). What happened that made you stop writing Amiga games?
The opportunity of writing SWIV for the Super Nintendo came along. The prospect of programming for games consoles was just too exciting to pass up. And, as it turned out, a great career move.
Do you know what happened to the Sales Curve/Storm after you left?
They went on to make many more great games, changed the name to SCi, went public 1999... it's all on wikipedia.
At the Sales Curve, did everyone work in a big open plan area, or you had little cubicles or rooms each?
In the days of Silkworm, the entire company was in a single largish open room. I remember we had trestle tables and patio chairs. During The Ninja Warriors, John and I worked from Jane's not yet occupied new home. Ned was still in the main office. By the time of Saint Dragon and SWIV, Ned had his own room (so he could smoke), and John and I were in a room of four - don't ask me the names of the other two programmers. For Rodland, I believe I had a room to myself. I worked on Super SWIV by myself from home, where I put in a lot of late nights and weekends.
Do you by chance have any old photos of what it looked like?
I don't have any. Some pictures were taken for magazine articles, but I wouldn't know where to start looking.
Do you remember your Amiga days fondly? Was it a dream job at the time?
Yes, of course. It was my big break, and I loved doing it.
Do you find it surreal that there are so many retro-gamers that catalogue games, rip music, extract maps, graphics, disassemble games and build websites with all the info? Far more effort into preserving history than almost any company at the time would have done!
It makes me feel OLD! :)
Your name seems to have shrunk from Ronald to Ron and you've dropped the Weeserik part!
I started using Ron when I moved stateside. I only use "Pieket Weeserik" when I open a bank account or something.
When did you move to the USA?
What are you up to these days?
I'm still in the games industry, but working a little more behind the scenes. The last games that I worked on, start to finish, were Mercenaries: Playground of Destruction and Mercenaries 2: World in Flames. Nowadays I work at Insomniac Games, as a tools programmer. The custom tools that we made for our Amiga games never worked very well. But there were only a few hundred sprites and a few dozen sounds, and only two or three people using the tools, so we improvised and took it in our stride. But a modern game can involve tens of thousands of files, teams of 60 or more people, so there is a lot more at stake. If tools aren't quite right, we can quickly lose hundreds of hours of production time, that could otherwise have been used for making the game more fun. I find solving this problem endlessly fascinating, and I think I can make more of an impact on the production of a great game, than if I were to write another renderer or animation system.
Thank you for answering so many questions! It has been a pleasure interviewing such an Amiga legend!
It's been fun. And thanks for your interest, Ian!
Ronald Pieket Weeserik Softography
ST Code: John Croudy
Graphics: Ned Langman
Music: Barry Leitch
ST Code: John Croudy
Graphics: Ned Langman
Music: Ronald Pieket Weeserik
Graphics: Ned Langman
Music: John Croudy
Some Sound FX: Ronald Pieket Weeserik
ST Code: John Croudy
Graphics: Ned Langman
Music: Andrew Barnabas
ST Code: John Croudy
Graphics: Ned Langman
Music: Ronald Pieket Weeserik