NLSC Your source for basketball video games.
We’re at midcourt, and the ball is about to go up…it’s Monday Tip-Off! Start your week here at the NLSC with a feature that’s dedicated to opinions, commentary, and other fun stuff related to NBA Live, NBA 2K, and other basketball video games. This week, I’m tipping things off with a frank discussion of how we can be ignorant about game design, particularly when it comes to programming.
Although I gained some experience with programming way back in high school, I’m not a programmer or software engineer. I’m not fluent in code, nor do I have any experience in developing or designing video games. Like a majority of people that play video games, I’m just a consumer; an outsider when it comes to the industry. I say this because I don’t want to present myself as an infallible expert or come off as though I see myself as superior to anyone else. After all, I disdain a content creator with a massive ego and foolhardy overconfidence in their knowledge and expertise.
With that being said, and at the risk of sounding egotistical or pretentious, I do know a thing or two. Aside from dabbling with programming at school and messing around with computers both professionally and recreationally, I’ve spoken to people who do know what they’re talking about. Running the NLSC for the past twenty years has granted me opportunities to gain insights into the development of basketball video games, and some of the technical aspects of game design. A recent Forum post asking about Next Gen features in the Current Gen version of NBA 2K reminded me of some misunderstandings about game design, and inspired me to provide some explanations.
Questions about whether or not certain features can be added are completely valid, as are queries about elements of games that are removed. Now, there are reasons that have nothing to do with programming and technological limitations, but rather game design philosophy. Evergreen examples would include designing modes in a way that frustrates gamers into spending money on recurrent revenue mechanics, or eschewing realistic ratings in order to facilitate desirable OP super cards in MyTEAM. These are design choices intended to achieve specific goals, rather than a fundamental aspect of game development. In other words, microtransactions aren’t a technical necessity.
Conversely, it isn’t possible to keep adding to code perpetually and indiscriminately. I sometimes get the impression that there are gamers who believe the programming side of game design is akin to creating a document in a word processor. In such a scenario, you’re working with plain language, and you can keep adding content at the end of the document. You can also go back and easily edit anything in the document without ruining what you’ve written (and usually fix it rather easily if you do). This isn’t the case with programming. You can’t just keep adding new content infinitely, or squeeze it into the existing code, and expect everything to keep working properly (or at all).
As such, as much as annual sports titles are accused of being copy and paste releases, there’s a lot of code that needs to be rewritten every year to accommodate the new features. Obviously this doesn’t mean that the whole game is built from scratch; there are assets that are reused, and a game’s code will bear similarities to its predecessor. However, these rewrites are necessary in order to ensure that the code for new modes and features is properly integrated with what’s already in the game, and won’t cause any crashes. To that end, that brand new code can’t just be slotted in at the end or seamlessly added elsewhere, and not cause issues. Again, it’s not a word document.
Incidentally, this is why we sometimes lose features and functionality, because the old code doesn’t work with the new code. A new feature or innovation is thus prioritised over one that telemetry data indicates isn’t popular, and the old feature is removed. That brings us to the common belief that features are removed just to bring them back and promote them as being new to sell future games. I won’t say that that’s definitely never happened, but there are often technical reasons why things are removed. Short development cycles for annual sports games lead to axed features – if only temporarily – if there isn’t enough time to have everything included and working in the rewrite.
It’s the same reason we don’t always see Next Gen features ported to Current Gen, even when the tech of the older platform isn’t a barrier. For example, none of the features in MyNBA in the Next Gen version of NBA 2K21 should require more powerful tech than what’s in the PlayStation 4 or Xbox One (or for that matter, your average gaming PC). However, getting MyNBA into Current Gen wouldn’t just be a matter of copying and pasting the code. It would require code to be rewritten, which comes down to available resources, namely time and manpower. It may be possible, but then there’s the matter of financial incentive, and prioritising other developments.
In short, even if it can technically be done, game design – especially for an annual release – requires difficult decisions to be made when logistics are involved. Using the example of replacing the three franchise modes in Current Gen with MyNBA, there are features that are coded to work a certain way, from the number of teams to the sim engine. Again, replacing them isn’t just a matter of pasting the MyNBA code over the top of MyLEAGUE, MyGM, and MyLEAGUE Online. Yes, it’s a selling point for Next Gen, but the work required to adapt the mode does take time and resources away from developing other aspects of the game. There’s no quick method to implement it.
I say this because I get the impression that some gamers do believe that that’s how it works. Many years ago, a Forum member suggested – and I’m paraphrasing here – that 2K should bring in Phil Jackson to inspect their code, and tell them what to delete. There’s a lot to unpack there. First of all, while he was a masterful coach, I don’t think Phil Jackson is an accomplished computer programmer. He’s not going to spot coding errors or shortcomings. Second, the notion that just deleting some code would fix the game is absurd; both the idea that removing rogue lines of code would be the key to improving the gameplay experience, and that it wouldn’t cause a ton of crashes.
The idea that this is how programming and game design works is what gives rise to the overuse of the word “lazy”, and various conspiracy theories. Obviously, there are certain game design decisions that are made for business reasons, particularly when it comes to recurrent revenue mechanics and new consoles. Like I said, the reasons for things being a certain way aren’t always technical. At the same time, it’s a fanciful thought that a basketball guru could be brought into the studio, look at a programming language they don’t know, and declare a solution that the developers are apparently too incompetent or lazy to see; one achieved with a press of the Delete key, no less!
By the way, this is something that I didn’t appreciate or understand until I’d spoken with people who were far more experienced in software and game design. I too would’ve figured that the previous game’s code would be a foundation to build upon. In some ways it is, but harkening back to my analogy of producing a word document, the way it’s been described to me, it’s more like starting with a new document but knowing what you want to say and how to say it. From there you’re writing it again fresh with the ability to add new text and other elements that flow the way you want, without having to worry those earlier paragraphs won’t gel with what you write later.
There’s another aspect of game design that I don’t think is talked about or appreciated by gamers, and that’s how it differs to modding a completed game. Over the years, there have been modders that have sneered at developers, believing they could do the job better. There’s a stark difference between coding a game, and hacking the files of a finished product. The files that we work with do not look the same while the game is being developed, and hasn’t yet been compiled. It’s much easier to open and modify a file in our operating system than it is to alter the raw code that they’re working with. We can make some impressive mods, but it’s not the same as software development.
If you’re sceptical, allow me to use another analogy. Let’s say someone creates a retro season roster. They’ve added all the necessary players and most of the artwork, and made the project public. Someone else comes along and changes some ratings or fixes lineups, resulting in a more accurate roster. Who had the harder job: the person who created all those players and put everything into place, or the one who tweaked the finished mod? The answer is the first person, and it’s why many roster modders are leery of allowing their work to be used as a base. Ultimately, for all the wonderful things that we do with modding, we’re editing the developers’ finished work.
My goal here is not to dismiss criticism, or deny that business decisions impact the games we play in ways that we don’t like. It’s not my intention to say “video game development is hard, knock off the criticism”. I do think that it’s important we know a few things about game design, because it answers questions we have about why things are the way they are, and helps us give better feedback. When we know a few things about how coding works, we can understand why features are removed, take a while to implement, or don’t end up being included in a prior gen release. The question is always whether it can be done in the allotted time, and without breaking everything.
Sometimes the answer is no, and while that’s disappointing for us, it’s something we can understand if we refer back to the word document analogy. Coding isn’t like typing up an article or story in plain language, where new text and other elements can be added or edited in without ruining everything. As for modding, I hope that the roster analogy aptly explains how we’re given a head start that the programmers don’t get. Yes, there are business decisions that aren’t pro-consumer, and we can (and should) criticise such practices. I’m all for that! It’s important that we understand game design though, and that what seems simple to accomplish isn’t always so.
