NLSC Podcast #310: Interview with Rod Reddekopp

NLSC Podcast Logo

Episode #310 of the NLSC Podcast is out now! This week’s episode tips off the next phase of our 25th Anniversary of NBA Live celebrations as I chat to Rod Reddekopp, programmer on NBA Live 95-2001.

Rod Reddekopp joins the show to talk about his time working on NBA Live, beginning with the acquisition of Distinctive Software and his early work with EA. From there, Rod takes us through the years, from the revamp of NBA Showdown into NBA Live, to the way the game grew and became a flagship property for the company. Along the way, Rod describes his various roles as a programmer on the series, as well as many of the technical aspects of the early NBA Live titles. He also shares some fun stories from behind the scenes, and reveals a few Easter Eggs for us to go hunting for.

Tune in below!

I hope you enjoyed Rod’s insights into the early days of NBA Live! Sound off in the comments section below, or join in the discussion here in the Forum! Additionally, feel free to hit us up with any feedback on the episode, as well as suggestions for topics that you’d like to hear us discuss in future episodes. For more information on the NLSC Podcast including episode guides, check out this page in our Wiki.

Support The NLSC on Patreon!
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
February 11, 2020 3:34 pm

Regarding differences between how games used to be made and how they are now, I think I have a more interesting answer than what I said in the podcast. On the older systems, particularly 16-bit consoles like the Super NES or Genesis, art had to be provided in a very specific way. Like “You have this many colours. The colour palette has these limitations. You have this many pixels.” And so on. The programmers were very much “the boss”, and artists had to do what we needed in order for the game to work. Even the early days of 3D engines were a lot like that. With more recent, powerful hardware, programmers are more like the servants of the artists. We are there to help them achieve their vision. Of course technical considerations are always present and sometimes we still need to help them understand limitations, but it’s definitely a shift in balance. Interestingly, I think I enjoy both approaches approximately equally, maybe with a slight edge to acting as the artists’ servant. It feels good to make beautiful things, which is basically an artist’s job description.