Robotron 64 developer retells his experience of working on the N64 and PS1

I was recently going through a long backlog of “leave it for later” bookmarks that I had in my browser, all the way back from 2012. Sifting through and endless amount of broken links and dead websites, I came across this gem that I found on Quora and saved to my list about 8-9 years ago. Someone asked the question “What was it like designing video games during the Nintendo 64 era?” to which a developer for Robotron 64 wrote a lengthy response.

My experience with all these broken links is making a bit anxious about whatever is left going offline, so I’ll be backing up the entirety of the text here in case Quora decides to purge it at some point.

I personally really liked this comment because it was from long before I started covering N64 homebrew and development on this website so it was a rare insight into how things worked without being the watered-down PR-filtered version we usually get.

I worked in games during that time, specifically on games for both the Playstation 1 as well as the Nintendo 64. During that time, I worked on several titles, but I’ll go into the history of one specifically (that ended up on both systems). I was the primary engineer on Robotron X for the original PlayStation, and I worked as a senior engineer on the N64 version of the same game, Robotron 64. Neither of these games turned out the way that I think any one of us would have liked, but looking back it, it serves as a good example for your question.

All of us who worked on the team were fans of the original Robotron. We liked the game for its high energy and extreme challenge. Although a sequel had been made before (Smash TV), which was successful in its own right, many of us felt that it lost the energy and “twitchiness” of the original. We also thought that Robotron, with its algorithmically generated content would be an ideal candidate for the limited resources available on the PS1.

The PS1 had a polygon rendering limit of roughly 3000-4000 triangles per frame at 30fps, and 1500-2000 per frame at 60fps. In our calculations, we thought we could design enemies that would be less than 100 triangles each, and with that hoped we could get enough enemies on screen to re-create the original robotron, in all of its 8 bit glory, but in 3D. The only art assets it needed would be the characters themselves, so we felt we could fit it into the memory of the system (less than 2MB), and therefore stream the music from the game from the disk.

We signed a contract, and I was the only engineer on the Playstation version (and the only one with a development kit). I had roughly 11 months to complete the project from start to finish, but we hoped I would have a head start as another engineer had started work on the game portion using a PC rendering engine, and my job would be to take that game code and get it running on the PS1. By the time I had received my development kit, I believe we had already used up some of those 11 months, but the game was relatively playable on the PC and seemed to be shaping up OK, but I had a long way to go to get it running on device.

The first issue we ran into is that memory access on the PS is *very* slow. The game, even without any graphics running at all, ran at less than 30 fps because of its extensive use of floating point. My first job was to convert all of the existing code to integer code, which unleashed a whole set of different problems around getting things scaled correctly, and getting things to move the way we wanted (particularly around collisions). Once I had the game running at a decent speed, I had to start working on rendering code. Even though our transform and rendering code was quite fast, there was too much stuff on screen, and the poor device just couldn’t keep up. This meant that we had to start changing elements of the design itself to try and stay under limits.

Our primary goal was to reduce the number of triangles we were drawing, and we had cut down our graphics to as low as we could. We used primarily gouraud shaded but un-textured triangles to maximize our rendering, and cut down on the number of triangles. Our median triangle count per enemy was around 80 polygons, so we were well under the limit we had set for ourselves. This still wasn’t enough to account for the overhead of the game code itself running, and so to reduce the budget, we had to speed it up.

Unfortunately, by this point, we were late into the schedule, and we had all been working 10+ hours each day in our compressed schedule to try and get the game done. I was still the only one with a Playstation development kit, but I hadn’t written the game code itself, so changes were relatively slow. Our build times were around 20 minutes, and that didn’t count the overhead of making the changes themselves, nor to play up to the point we wanted to test. The first change that was made was to have the enemies “warp” into the level as you killed them, so that the game was processing less enemies. Our hope was that we could find other ways to improve the speed and we could take these changes back out, because it fundamentally changed the way the game itself played.

Around this time was the same time we added our streaming music. Unfortunately, this had the side effect of using up a significant chunk of our precious memory bandwidth, and had an effect on our rendering speed. Now we were not only over budget on our CPU, but on our graphics processor as well. To correct this issue (and keep the game playable), we zoomed the camera in to reduce the number of enemies being drawn. This also fundamentally changed the way the game played, and made us have to remove the “classic” mode we had put into the game, with a purely overhead camera from the same perspective as the original.

None of us were happy with the changes, but we were running into Christmas deadlines, and after close to a year of working 7 days a week, the product shipped. In retrospect, I’m very unhappy with how the product turned out, but was relieved at being able to ship it. Although we made a number of mistakes during production that would have improved the product, in hindsight, I think we were over ambitious with relatively new and unknown hardware and a tight schedule, and so our project may have been doomed from the start. We hoped to rectify these errors with the second version of the game, Robotron 64, which was due for release on the Nintendo 64.

On the second title, I was no longer the only engineer (nor the lead, due to both scheduling, timing, and being overworked from the first project). The Nintendo 64 version had a couple advantages over the first. The big advantage it had was it got to start with an existing code base who’s weaknesses and strengths were already known. The Nintendo 64 also had very *very* fast memory (for the time), no load times (being on a cartridge, you can address memory directly). It also had a higher rendering budget, but since the art had already been created for a lower end platform, it had all sorts of extra rendering budget to utilize. Finally, it couldn’t stream music, which required righting a tracked music player, but it also didn’t consume a large portion of the memory bandwidth. This project was finished in a similar amount of time as the original (I believe slightly less, but I could be wrong), but it was a relatively sane project, without the same sort of crazy hours. It also turned out to be a much better game because of it.

In the end, when I look back it and the lessons that were learned compared to what it is like making games today, and I come to the following conclusions. Making games fun is difficult, and very few games are hits. If you don’t have a significant amount of time to “tune” the game and make it fun, your chances of success are very low. Having to deal with technical limitations causes 2 major problems. The first is that the limitations of the hardware end up dictating the kind of game you can make. Games today still run into hardware limitations, but those are generally around visual performance, and rarely do you run into limitations on what you can do from a gameplay perspective. It may not look as nice as you like, but it its still possible to do some version of it (as opposed to previously). The second problem is related to the first, which is that the more time you spend on the technology itself as opposed to the gameplay, the less likely you are to succeed. With the shorter schedules, you had less time to react and correct, and so your mistakes would consume a larger portion of your overall schedule. In the end, it is amazing that we got the games out at all. The Playstation and the PC version of Robotron were completed in less than a year’s time, by a company that consisted of 5 people total. The Nintendo 64 port was completed by roughly 3 full time people in less time than the original. You would be hard pressed these days to complete a single game in the time we did 3, and it would be impossible with the small staff we had. At the same time, I practically killed myself working on those projects, as did many of the people involved, for games that were not a commercial nor a critical success, and is one that I personally felt embarrassed about for a long time (being a fan of the original). Since then, I’ve learned not to beat myself up for past mistakes and learn from them instead. Its easy to glamorize the past and what it was like, and I’m not sure how I would have done things differently, but I hope I never have to repeat that experience again.

Tom Ketola

The development journey with Robotron X and Robotron 64 for PlayStation 1 and Nintendo 64 respectively, was defined by navigating technical hurdles and gaining insightful lessons from experience. From addressing memory access issues to optimizing rendering performance within platform limitations, the team adapted to the constraints of the PS1 while striving to preserve the essence of the original game.

Transitioning to the Nintendo 64 brought advantages like faster memory access and cartridge-based storage, facilitating a smoother development process and yielding a higher-quality end product. Despite challenges and compressed schedules, these experiences underscored the importance of balancing technical constraints with gameplay considerations and the need for iterative refinement in game development.

Overall, I do think that this insight does provide us with a nice look into what it was like making games for consoles back in the day.