I sat down with two original NBA 2K and NFL 2K engineers to learn how they helped build the two iconic sports games and I ask: can 2K Sports make a return to NFL greatness?
Based on Sega’s NAOMI architecture, the Dreamcast would offer a glimpse of what advanced computational processing and graphics processors are capable of today. The Dreamcast offered buttery smooth frame rates, and was one of the first machines to offer competitive online sports gaming. Even more, Sega Sports, with its slow-motion instant replay systems and its patented 2K-camera bokeh, created the illusion that the 2K Sports world was alive — and I wanted to learn more about how these games were made.
I spoke with two different tools engineers on the original NBA 2K and NFL 2K development teams to learn about the technical, translational nature to their work on what was the new Sega Dreamcast hardware. What follows is a rare, unexpected, and deeply technical look inside the original 2K Sports, exploring how Sega and Visual Concepts created the foundation of NBA 2K and NFL 2K.
Custom Tools Engineering and Maya
DCJY: May I ask if you worked on gameplay or designed tools for the games?
2K Engineer (One): I was a tools engineer, mainly writing exporters and customizations for Maya. As far as I can recall, at the time VC did not have dedicated design staff. Design was done primarily by engineers and artists. Greg and Scott, the founders, also contributed to design.
Excellent. What kind of exporters and customizations for Maya? Anything gameplay oriented or for ratings, or for visuals? Player ratings are usually very mysterious for sports games players.
2K Engineer (One): Exporters were mainly about modeling and animation. Modeling includes level design, e.g. stadiums, lighting, and character design. Character animation started as mocap data, which always needs a lot of cleanup. For example, mocap will typically clamp rotations to +/-180 degrees; that can result in a discontinuity when the source data crosses the threshold. Things like the peak of a sinusoidal wave that crossed the limit will be snapped 360 degrees to the other side. Mathematically they are equivalent, but it’s confusing to see, and can introduce sampling errors along the discontinuities.
So I’d create Maya plugins that would automate curve clean-up, or to apply various lighting tricks, or other things to automate tedious work that artists and animators would encounter. Sometimes I might add custom user data to the elements in Maya; these would tend to be more design oriented. Ultimately it would all get exported in formats that could be consumed by the game engine.
Things like player stats were tabular, maybe done in Excel. I don’t remember specifically, but that would make sense.
Thanks for this breakdown. I think this explains a lot of things that come up in games, like clipping, and various quirky animations that need those custom solutions.
Editor’s Note:
The turn of the millennium gave way to the rise of 3D sports gaming and powerful hardware. With better hardware technology, new software was developed to take advantage of the new capabilities that the Dreamcast now offered. With new software came new programming languages, new disciplines, and the demand for cross-disciplinary skilled workers to make sense of it all.Tools engineers and technical artists would prove to be a key for Sega Sports and Visual Concepts in maximizing the Dreamcast’s capabilities from launch.
Lighting and Camera Technology
2K Engineer (One): The lighting you mention might have been in a later generation. I’m pretty sure in the 2K, 2K1 generation the lighting was mostly static, and lens effects would have been pre-rendered. I *think* I remember someone experimenting with shadow casting for 2K1, but it was too expensive for production. Four or five years later more sophisticated lighting and camera effects started popping up.
Oh, good distinction. Yes, maybe what I am referring to gave the implied dynamic lighting effect, but perhaps was not dynamic just yet. But at least the camera focus length and bokeh was very unique then on 2K and 2K1 with the blurred backgrounds and focused subject in the replays.
Did you contribute to the replay tech, by chance? Everything about it animated so smoothly. And did you contribute to any physics work?
2K Engineer (One): No, I was not involved in any runtime tech. I did collaborate with engine programmers to work out data representations, and occasionally would join for debugging sessions when we were trying to figure out where problems lay.
Editor’s Note:
The runtime technology referred to by the 2K Engineer is the game engine, where the final game will run and play. The tools engineers worked collaboratively with technical artists on Maya, and with the game engine engineers on the Dreamcast runtime side, working to create a translatable pipeline between the two environments.
As alluded to above, Maya was used to develop animations for players down to each joint in the body, and oftentimes the animations needed work once they reached the game engine environment. Thus, the tools engineers had to understand the specifications of both programming environments and this is why I consider them linguists of computer programming languages. This complex work was required because Maya was still being introduced to game development in this era.
The Sega Dreamcast hardware had new capabilities and demanded new workflows. Solutions were needed and built. The graphics, lighting, and game animations were exceptional as a result — Sega Sports had a talented team working with powerful, novel technology in what proved to be quite a formidable formula.
The Game Development Landscape in 1999
Okay, that’s interesting. Were Maya and SGI what the film industry used? Was it unusual for a game company to use Maya and you were creating a lot of solutions to bridge Maya to the game engine?
May I ask for any thoughts you might have on the Dreamcast hardware and dev kit and where does it fall into the work with Maya and the game engine? I am thinking maybe the work you performed helped 2K get its graphical edge and 2K even maintained it pretty well after the PS2 launched.
2K Engineer (One): In that era, SGI was the main platform for film production. There were a number of apps built on IRIX (the SGI version of UNIX). Two big ones were Power Animator (Alias) and Wavefront (Wavefront). Alias and Wavefront merged to become Alias/Wavefront, and started working on a best-of-breed hybrid that leveraged the best of each; this became Maya. Somewhere along the line SGI acquired Alias/Wavefront. And then later sold off to Autodesk, who ultimately wound up acquiring just about all the similar apps.
Currently, Maya is widely used in both gaming and film. At the time we started on the 2K games, Maya was new. We started on v1.5. Prior to that we used Power Animator.
I think the most common modeling and animation applications for game companies at the time was 3D Studio MAX. 3DS was originally developed for DOS, but migrated to Windows NT. It was more of a budget product. However, a number of studios, as exemplified by Visual Concepts, used apps running on SGIs.
On Dreamcast and Naomi Architecture, Graphics, and Maya
I don’t think Maya drove the engine development. Apps like Maya have a lot more modeling and rendering capability than runtime engines because they don’t have realtime constraints. So the trick is to bleed as much realtime capability out of the hardware as possible. Among the techniques is optimizing the data to suit the engine. You need to take the representations in Maya — built for modeling and editing — and boil them down to what can be expressed in the engine, and nothing more. That’s a slightly simplistic explanation, but is sufficient for now.
What you can infer is that the artists working in Maya have a sense of what native features are expressible in the engine, and how. Part of the job of the toolset is to move data out of Maya as unobtrusively as possible, and to provide guidance when the Maya data is not expressible, and hopefully provide diagnostics to help the user adapt.
So I think the best answer about where 2K gets its graphics capabilities is from the engine engineers. The rest is about giving content creators a low-friction, expressive path [from Maya] to the engine.
By the way, we’ve glossed over 2D data. All the images used for texturing also require a pipeline. PhotoShop is a common authoring tool. For Dreamcast, textures had to be compressed in a format colloquially called “twiddling” that PhotoShop did not support natively. I wound up creating a program to do the compression; I can’t remember if it was stand-alone, or wrapped as a PhotoShop plugin. I might have set it up as both, but y’know, it was a long time ago.
This is great detail. Thanks for such a thorough answer.
That’s interesting about translating dev. kit documents from Sega. I spoke with another member of your team who mentioned her expertise in translating from Maya to Dreamcast format, too. So in this sense, it sounds as though there was translation for various coding languages; and also from Japanese to English that had to occur in the early development for Dreamcast games and 2K Sports games! That in itself is quite interesting and fascinating. Challenging.
Editor’s Note:
Here, 2K Engineer One makes sure to correct me in describing why the 2K Sports games had exceptional graphics. The Dreamcast game engine engineers were taking full advantage of the novel hardware from the onset, having reverse engineered the development kit; they also had some support from Sega of Japan by way of development kit guidance documents. Maya, on the other hand, allowed technical artists and animators a sandbox to design and experiment, while they were keeping in mind the final runtime constraints of the game engine before porting.
I’d like to highlight the artists here, too. Technical artists designed the carefully-sculpted player models. NBA 2K featured impressive and lifelike player face scans, animated facial expressions, and a variety of player archetypes and builds. The personalized archetypes and builds particularly contributed to the realism in the NBA 2K physics.
Suffice to say, the diverse team synergy at Visual Concepts was locking into place. One additional and key reason why is because Visual Concepts hired an experienced tools engineer directly from Autodesk (Maya) to lead the custom tools engineering on the 2K Sports games. With a master’s degree in Mathematics from a top ranked U.S. science university, the Lead Software Engineer could speak Maya’s custom programming language and the Dreamcast’s runtime specifications, too. I liken their role to one of a cross-cultural interpreter for code. In speaking with the second engineer (2K Engineer Two), I found them to be highly technically knowledgeable and a willing teacher. In our conversation, they thoughtfully began explaining how 3D technology works at the most fundamental level, because at its core, 3D player models can be expressed [purely] in mathematical terms. The talented lead engineer helped guide a segment of the dev-team to deliver incredible sports games and technology for the Sega Dreamcast U.S. launch in September of 1999.
In all, one can surmise the custom solutions and translation pipelines were being built on the fly and from the ground up, pointing to the impressive skills across the board at Visual Concepts and Sega.
Cross-Discipline and The Rise of Technical Artists
2K Engineer (One:) You touch on several topic here that I want to address, but for now let me just focus on the last:
It sounds like in order to give engineers and artists an expressive path to the game engine, you had to be well versed in both environments.
2K Engineer (One): Yes, and more than that. An aspect of my role involved being a cross-discipline diplomat.
Historically, game development was very engineering-centric. Sometimes games were released with “programmer art,” that is, clumsy art that programmers knocked out in order to exercise the game. (Bomberman for SNES might be an example.) Over time devs came to recognize that there were people — artists! — who might be more skilled at this, and it was more effective and gave better results to include artists in the process.
However, programmers tended to be somewhat high-handed, where artists were regarded as “the help.” (And yes, I am painting with a broad brush.) A lot of repetitive work was foisted off; artists’ time was not considered as valuable as programmers. Artists were given a lot of procedural constraints in how to prepare their work, told “just do it this way, push that button, give me the file and mind your own business.”
This was a cultural norm.
As capabilities of consoles and PCs grew, so did the need for content, and expectations for the quality of the art increased. Devs started to recognize value in providing better tools for the artists.
So part of my role involved understanding what data the runtime required and figuring out how to facilitate artists in producing it. Sometimes artists would observe, “Look, here’s a thing I can do in my authoring environment, and it seems like it could be achievable on the platform.” I’d be an advocate for the art team and help evaluate technical feasibility of the proposals.
Another part of the role is to check in with content creators to understand what are pain-points in their processes, and assess if there’s any tooling that might mitigate the problems. There was one art director who would often stop by and tell me about some PITA thing he was doing, and ask if I could make some button that would do it for him. Most of the time I’d have to say I don’t see a way to do that, but occasionally we’d hit pay dirt. Over time, the tools got considerably more effective.
I think over the late 90’s and early 2000’s, the culture shifted. Content creators are recognized as peers to Engineering, and Design as a distinct discipline became more common. In fact, in my opinion, some of the best games are from design-centric studios, e.g. Blizzard, e.g. Maxis. At the end of the day, players are not admiring the async protocols for fetching leaderboards, or how the code determines if a door is locked, or how to select the right reaction animation for a shotgun blast. They care about the goals of the game, how you interact, what’s the narrative, etc. They care about design.
These days, there’s a role of Technical Artist, someone who is fully competent as a production artist who is also skilled at programming. This is sort of a complement to an engineer creating art tools. Often they are customizing art tools. Another area they shine at is creating shaders. Shaders are programs that execute on the graphics accelerators; they are key for high performance, and for a lot of the fancy rendering effects.
I think Tech Artists (sometimes called Tech Director) were a common role in the film industry long before it was adopted in gaming. In the last 20 years, though, it’s become the norm in gaming, too.
Wow, okay. Very insightful, especially because of the graphical and processing power leap with the Dreamcast. and Ps2. This is a window into how the turn of millennium consoles may have required more out of artists and tools engineers.
I like the comparisons you’ve made. So these technical artists would be somebody to work with the tools designers. Very cool.
It sounds like in order to give engineers and artists an expressive path to the game engine, you had to be well versed in both environments.
2K Engineer (One): Yes, and more than that. An aspect of my role involved being a cross-discipline diplomat.
Historically, game development was very engineering-centric. Sometimes games were released with “programmer art,” that is, clumsy art that programmers knocked out in order to exercise the game. (Bomberman for SNES might be an example.) Over time devs came to recognize that there were people — artists! — who might be more skilled at this, and it was more effective and gave better results to include artists in the process.
However, programmers tended to be somewhat high-handed, where artists were regarded as “the help.” (And yes, I am painting with a broad brush.) A lot of repetitive work was foisted off; artists’ time was not considered as valuable as programmers. Artists were given a lot of procedural constraints in how to prepare their work, told “just do it this way, push that button, give me the file and mind your own business.”
This was a cultural norm.
As capabilities of consoles and PCs grew, so did the need for content, and expectations for the quality of the art increased. Devs started to recognize value in providing better tools for the artists.
So part of my role involved understanding what data the runtime required and figuring out how to facilitate artists in producing it. Sometimes artists would observe, “Look, here’s a thing I can do in my authoring environment, and it seems like it could be achievable on the platform.” I’d be an advocate for the art team and help evaluate technical feasibility of the proposals.
Another part of the role is to check in with content creators to understand what are pain-points in their processes, and assess if there’s any tooling that might mitigate the problems. There was one art director who would often stop by and tell me about some PITA thing he was doing, and ask if I could make some button that would do it for him. Most of the time I’d have to say I don’t see a way to do that, but occasionally we’d hit pay dirt. Over time, the tools got considerably more effective.
I think over the late 90’s and early 2000’s, the culture shifted. Content creators are recognized as peers to Engineering, and Design as a distinct discipline became more common. In fact, in my opinion, some of the best games are from design-centric studios, e.g. Blizzard, e.g. Maxis. At the end of the day, players are not admiring the async protocols for fetching leaderboards, or how the code determines if a door is locked, or how to select the right reaction animation for a shotgun blast. They care about the goals of the game, how you interact, what’s the narrative, etc. They care about design.
These days, there’s a role of Technical Artist, someone who is fully competent as a production artist who is also skilled at programming. This is sort of a complement to an engineer creating art tools. Often they are customizing art tools. Another area they shine at is creating shaders. Shaders are programs that execute on the graphics accelerators; they are key for high performance, and for a lot of the fancy rendering effects.
I think Tech Artists (sometimes called Tech Director) were a common role in the film industry long before it was adopted in gaming. In the last 20 years, though, it’s become the norm in gaming, too.
Wow, okay. Very insightful, especially because of the graphical and processing power leap with the Dreamcast. and Ps2. This is a window into how the turn of millennium consoles may have required more out of artists and tools engineers.
I like the comparisons you’ve made. So these technical artists would be somebody to work with the tools designers. Very cool.
Editor’s Note:
What an important distinction here. The new technologies of the 2000 era demanded more from artists. This gave rise to technical artists in game development. Technical artists, tools engineers, artists who crafted custom shaders, and others were all in on the development.I’d like to pause here. Given the current moment, where artists and programmers are being dispensed with and those roles increasingly likely to be handed over to AI (See: Microsoft to cut up to 9k jobs as it invests in AI), the distinction here is clear. 2K Sports was built on the technical prowess of its talented technical artists and engineers, who 2K elevated when the technology required it. For modern day game publishers to ignore their roots in the name of increasing revenue per share is to ignore how the best studios made a name for themselves — through cultivating talent and cross-collaboration.
As mentioned, artists were often overlooked prior to the 3D era. But when we look at some of the best games that have withstood time, we can look at games like Street Fighter III: 3rd Strike and Street Fighter Alpha 3 on the Dreamcast, with incredible 2D art, animations, color tones and layered level designs. Further, on the point of technical ability, Nintendo has worked magic with less-optimal hardware and Zelda: Breath of the Wild the most powerful example of what a dedicated, in-house team can achieve with the freedom to do so and leadership that understands that games are made by hiring and nurturing exceptional talent with generations of know-how.
On 2K’s Animation Libraries
DCJY: I wanted to also ask, if I may, about animation libraries, generally and how they might typically be built and work. Are the animations stored in a library and the engine calls them up if certain parameters are met? i.e. a button press to execute a tackle in a given context? I ask because 2K was known for its incredible depth of libraries — players can uncover new moves in rare instances and this kept things exciting. Especially in the basketball games as they became more advanced.
2K Engineer (One): Hmm, hard to know where to begin. There are two aspects: how animations are represented, and how animations are packaged. I’m going to focus here on mocap data, which is a special case for animation. Except for root motion (how the character moves through space), positions for each joint are represented strictly as a set of three rotation values. Moreover, positions are sampled at a fixed rate. For playing back at 60 FPS, typically you’d sample at a small integral fraction of that, i.e. 60-, 30-, or 15-FPS.
With that in mind, recognize that animation data is huge.
For each pose, for each joint, it takes 3 rotational values. Multiply that by the sample rate and length of the move, and it takes a lot of memory for a single move. Multiply that by the number of moves…well, it gets big.
Consequences that scale with the data size are how much run-time memory it occupies, and how long it takes to load. This can be mitigated by compressing the data, but it’s still going to be large enough to occupy a significant fraction of working memory.
Animation data in apps like Maya are typically represented using 32-bit floating point values. After export, you’d run it through a compression process prior to packaging it. At runtime, you’d load compressed data, and only decompress it for the frame you are currently rendering.
Understand that compressing data involves making a trade-off between data size and computation time to decompress. For the rotation use-case, 32-bit floats provide excessive precision and dynamic range. They were compressed to 8-bit integers. Converting back to floats at runtime is cheap using a look-up table.
Moves need to be cached into memory before they can be used. Load times are far too slow to use for dynamically determined moves. So in answer to your question about calling up a move on a button press, nope, too slow.
So when do special moves get loaded? It depends. Say a move is unlocked by a certain achievement; you’d load it when that achievement is triggered. Say it’s particular to a character; you’d load it when that character is loaded. Say it’s related to some prop (e.g. interacting with a vending machine); you’d load it with the prop. I’m sure there are other special conditions one could come up with, but you get the idea.
How are these things packaged into libraries? Common moves that will always be loaded can be packaged together, as they will always be loaded together. Think of things like walk cycles, run cycles, etc. Special moves would be in more specialized packages, and likely more granular. You don’t want to have to temporarily load a package of a thousand special moves to extract a single move.
There’s another category of animation techniques, physics-based animations, in which animations are modified by physical events. Consider, e.g., a character getting shoved while walking; you’d want to account for the direction and force of the shove. This can be done in real time computation, but it is expensive. This was out of scope in the 2K, 2K1 era except for some trivial cases. Today it is commonplace.
As for the depth of the libraries, well, you are talking about a lot of mocap! Usually mocap is recorded at specialized studios with suitable equipment and know-how. At the time of 2K, Visual Concepts actually built a mocap studio in their offices! This was the office in San Rafael. I don’t know if they continued with in-house mocap when they moved to Novato.
2K Engineer (One): Hmm, hard to know where to begin. There are two aspects: how animations are represented, and how animations are packaged. I’m going to focus here on mocap data, which is a special case for animation. Except for root motion (how the character moves through space), positions for each joint are represented strictly as a set of three rotation values. Moreover, positions are sampled at a fixed rate. For playing back at 60 FPS, typically you’d sample at a small integral fraction of that, i.e. 60-, 30-, or 15-FPS.
With that in mind, recognize that animation data is huge.
For each pose, for each joint, it takes 3 rotational values. Multiply that by the sample rate and length of the move, and it takes a lot of memory for a single move. Multiply that by the number of moves…well, it gets big.
Consequences that scale with the data size are how much run-time memory it occupies, and how long it takes to load. This can be mitigated by compressing the data, but it’s still going to be large enough to occupy a significant fraction of working memory.
Animation data in apps like Maya are typically represented using 32-bit floating point values. After export, you’d run it through a compression process prior to packaging it. At runtime, you’d load compressed data, and only decompress it for the frame you are currently rendering.
Understand that compressing data involves making a trade-off between data size and computation time to decompress. For the rotation use-case, 32-bit floats provide excessive precision and dynamic range. They were compressed to 8-bit integers. Converting back to floats at runtime is cheap using a look-up table.
Moves need to be cached into memory before they can be used. Load times are far too slow to use for dynamically determined moves. So in answer to your question about calling up a move on a button press, nope, too slow.
So when do special moves get loaded? It depends. Say a move is unlocked by a certain achievement; you’d load it when that achievement is triggered. Say it’s particular to a character; you’d load it when that character is loaded. Say it’s related to some prop (e.g. interacting with a vending machine); you’d load it with the prop. I’m sure there are other special conditions one could come up with, but you get the idea.
How are these things packaged into libraries? Common moves that will always be loaded can be packaged together, as they will always be loaded together. Think of things like walk cycles, run cycles, etc. Special moves would be in more specialized packages, and likely more granular. You don’t want to have to temporarily load a package of a thousand special moves to extract a single move.
There’s another category of animation techniques, physics-based animations, in which animations are modified by physical events. Consider, e.g., a character getting shoved while walking; you’d want to account for the direction and force of the shove. This can be done in real time computation, but it is expensive. This was out of scope in the 2K, 2K1 era except for some trivial cases. Today it is commonplace.
As for the depth of the libraries, well, you are talking about a lot of mocap! Usually mocap is recorded at specialized studios with suitable equipment and know-how. At the time of 2K, Visual Concepts actually built a mocap studio in their offices! This was the office in San Rafael. I don’t know if they continued with in-house mocap when they moved to Novato.
Another word about the animation compression. It’s the nature of an effective compression technique that the cost is in the compression process, and that decompression comes cheap. Credit goes to the runtime engineer who recognized the opportunity to create the tech.
Editor’s Note:
In a previous interview in 2024 with the lead producer on NFL 2K, he shared that Visual Concepts built a motion-capture studio in-house in order to capture all of the moves and data needed to build its game from the ground up. Was this studio a competitive advantage? I do think having the motion capture done in-house and having a direct pipeline to 2K’s studio was an advantage. For instance, the studio presumably allowed for the engineers to directly clean up the raw data in shorter time frames.To give a strong example of what the in-house studio produced, we can look at ESPN NFL 2K5. ESPN NFL 2K5 featured a create-a-player mode that gave game players access to an animation library within the game. We can browse through an endless list of animations ourselves to get an idea. Most importantly though, 2K Sports games have had the unique ability to keep player’s imaginations engaged because of the possibility of seeing a special move or play unravel in a way that we’ve never quite seen before. Between the timeless NFL 2K5, and today’s NBA 2K series, 2K Sports made its name in physics and animations in sports games.
On 2K Football Remakes and Remasters
2K Engineer (One): Like a remastering of the old titles? I think something like that would mainly be about using the old assets, and I don’t know from a design and art direction perspective what you’d do with them. Contemporary character models and textures are a lot more high resolution, and shader tech is way more advanced. If I remember correctly, animation was done for a 17-bone rig (standard at the time); contemporary rigs have a lot more bones, mainly affecting hands and facial animations.
As for porting gameplay, I don’t know if 2K [would be] using a derivative of the same engine, or if they [would] completely rework that. It is not unheard of to stick with derivatives of legacy engines; Madden is still built on Frostbite, for example. Even if it is an evolution of the original engine, it’s apt to have changed into something unrecognizable to the old systems.
Anyhow, all that is merely idle speculation on my part. I wouldn’t take it too seriously.
Editor’s Note:
While the capabilities are there for 2K to make another football game, it has been reluctant to do so. The key question remains: why? One can surmise a non-NFL remaster or remake is certainly possible per the former 2K Sports engineer’s answer. Maybe most importantly, his answer keeps the dream alive for game players to one day play a new 2K football game, modernized in powerful new hardware.So why hasn’t 2K Sports made another attempt at football games? The answer likely can be traced back to profits and licensing, and so the next logical question is whether or not a football game can overcome a lack of licensing. Can a non-NFL football game sell well enough to make the profits worthwhile? One could argue that 2K’s open-worlds in NBA 2K and WWE 2K thrive, (NBA 2K, to the tune of billions per year), and perhaps those game modes represent a pathway for a football game to have its own open-world ecosystem, where the money is made in microtransactions. In these worlds, licensing has little to no impact other than to pull gamers in.
Would a reverse formula work and would there be strong enough interest i.e., would an open-world football platform without the NFL shield appeal enough to game players? I would like to think so, so long as the underlying gameplay physics and technology is as good as the NBA 2K games. Otherwise, a poor playing football game and open-world would be a house of cards, built on weak gameplay, trying to sell you on the next wave of consumables.
The fact is the know-how and institutional knowledge to build a new football game still lives on, hidden within the walls of a select few cavernous airport hangars in Novato, CA — and many workers from the original development teams for NBA 2K and NFL 2K still remain in-tact, working on the NBA 2K franchise, infusing it each year with the innovations in presentation, animations, and more. Upon learning about the technical development of 2K Sports on the Dreamcast — some of the best sports games of a generation — it is clear to me that 2K Sports has the talent, capability, and funding to take on Electronic Arts. All it takes is the matter of will.
1 comment:
What a brilliantly in-depth interview. A lot of it went a little over my head but a great read, and a fascinating look behind the scenes of these sports games.
Post a Comment