Introduction
Software is a different kind of commodity from most. Unlike, say, a pair of boots, which are complete and whole at the time of purchase and may only need occasional care, software requires constant maintenance to remain functional. Bugs must be found and quashed, server downtime must be understood and prevented, and changes in the architecture of the game’s platform (a Pro version of a console, or a new operating-system version) must be accounted for. These are processes of maintenance and repair, but they are going to be familiar to scholars working in the history of software and computing.
This interview is with Austrian high-performance computing expert Dr. Peter Thoman, perhaps better known by his handle, Durante, under which he released his most famous mod: DSFix, for Dark Souls. This piece of software made the PC release of genre-defining role-playing game (RPG) Dark Souls playable in the eyes of many critics and players alike, allowing for proper rendering of different display resolutions and other graphical adjustments that were not present in the original port. Thoman’s work has remained one of the most downloaded mods for the game and is a useful case for examining the intricacies of maintenance and repair in the gray area of a practice sometimes actively supported by developers and sometimes intentionally deterred.1 This is the difficulty, as Thoman explains, of maintaining or repairing something designed and owned by another party. Like many contemporary modders, Thoman got his start in the modding scene through Bethesda’s Elder Scrolls III: Morrowind, where he sharpened his skills. He then moved on to academic research into high-performance computing and received his PhD in computer science from the University of Innsbruck in 2013. He is currently an assistant professor at the University of Innsbruck, with a current research focus on achieving high performance on parallel computer hardware. He is also the cofounder of PH3 GmbH, which specializes in software porting.
In this interview we explore Thoman’s career, which spans the video game modding scene, a university appointment as assistant professor at the University of Innsbruck, and the professional world of video game ports through the company he cofounded—PH3. While modding is often the purview of motivated members of a game’s community outside of formal developer/publisher environments, porting requires a certain amount of institutional support and jolly cooperation with the game’s developers or publishers. Thoman’s experiences with both let him offer a unique perspective on the challenges, demands, and creative pleasures associated with this work.
While we began the interview with a fairly clearly delineated sense of what parts of modding and porting can be considered maintenance and what repair, it quickly became apparent that this theoretical division breaks down in practice. And this was a good thing. There is nuance in the type of work that spans changes as straightforward as normalizing the size of the rats encountered in The Elder Scrolls IV and as complex as adding an entire act—story, dialogue, and animations—to Star Wars: Knights of the Old Republic 2. This messiness of definition is immediately apparent to experts in these practices, and recognizing this fact will help to ground theory as scholars increasingly move into this area.
But not all is maintenance, repair, or somewhere in between. At times Thoman strongly rejected that the work he and others perform is maintenance or repair at all, instead highlighting that the use of such terminology belies some other significant motivation for their labors. We should seek to be cautious as scholars transitioning to research in this area about leaping too quickly to labeling the practices we seek and have just encountered as falling under the purview of the new phenomena we are so keen to study, lest we devalue them. The tools and perspectives we present in this special issue are valuable ways of studying maintenance and repair but cannot prove their efficacy if applied too widely.
This interview took place on Zoom over about sixty minutes on February, 21, 2023. It was conducted by Logan Brown and Marina Fontolan and was recorded with the consent of the interviewee. The text has been transcribed, lightly edited for strength and clarity, and introduced by Alexander Mirowski. Our goal is to bring multiple disciplinary perspectives to the complexities of Thoman’s career.
Transcript
Peter Thoman [PT]: My name is Peter Thoman. I’m an assistant professor at the University of Innsbruck. But I don’t work with games there. I work on high-performance computing and, particularly, parallel runtime systems in high-performance computing. I started off game modding in the past—let’s say from [the age of] fourteen [up] to five years ago, so I haven’t done much modding in the last five years. Some years back, I founded this company and we do mostly game porting to PC, but also to consoles now. And yeah, that’s my background in both of those things. I’ve also been playing games probably for, I don’t know, thirty years at this point. So yeah, that’s me.
Logan Brown [LB]: Can you tell us just a little bit about your upbringing and education? And then where, for instance, you first got into games and where and how you first got into modding?
PT: Let me think back. So first got into games, I guess that was a friend of mine, a slightly older friend had a Commodore 64. And I was even too young to basically type stuff into that more or less, but I could move the joystick here, that’s more or less where I started playing games. I got more into it when we got our first IBM-compatible PC, and I guess that’s kind of my tie into the multimedia with the computer science bit.
It was [one of the] early versions of DOS in the beginning and, basically, just getting some of the games to run was a bit of an adventure. My father was typing out different kinds of config.sys files to make it load the right memory and stuff like that for different games, so that they would even work. I guess that’s why I got more into the technical aspect of it. So that’s the very early time when I started playing games.
In terms of modding … I think I probably actually started trying to write my own games before I started modding. I played around with C, basically, which was its own challenge at that point. So I think at that point I was probably like twelve or thirteen years old and was trying to write my own games. I first got [into modding] with Elder Scrolls III: Morrowind [Bethesda Softworks, 2002], which had a huge modding scene. And I was really into it because it was so simple to get something going and actually see some feedback immediately. And after that, I was doing some modding in other games all of which had a big modding scene, but really the first time I actually did any kind of, how do I say, unintended mod for a game was with Dark Souls [FromSoftware, 2011], which I guess is by far the most famous thing I’ve done.
Marina Fontolan [MF]: Could you talk a little bit more about your early experiences with modding? So, how was this transition from creating your own games to modding? Why did you choose to do so? I mean, if you have more examples besides Elder Scrolls III: Morrowind, which other mods did you do?
PT: Well, it’s always difficult for me at least to think about what can be considered a mod and what’s a separate thing and what’s just content for a game. I dabbled in making 3-D models for some games, I did other stuff like that, I wouldn’t really consider that the type of modding that I did more of later.
The problem I had with making games just as a hobby is that I’m also really into higher-end 3-D graphics, which ties in with the whole high-performance computing thing. And you, as a senior developer, who’s also doing something else, it’s not really viable to make your own high-end game in terms of assets, and all of that. So what’s fascinating to me about modding these games, and what’s always [been] fascinating, is that I can easily take like a game, which has all the assets already created and everything, and I can work exclusively on some rendering aspects of it. So for example there was one I worked a lot on ambient occlusion, and looked into all the research on that and how to implement it for this game, and I could do that without spending a lot of time working on everything else. I could get it to work in the game and I really liked where I could see the effects immediately and also where other people could appreciate it in the context of something that they were already playing. So that’s why I really enjoyed this type of modding where I just focus on some graphical aspect and can continue to work on that without having to go through all the other steps basically.
LB: So while obviously we’re on the topic of DSfix, as you said, that was the first mod of yours that made really big waves in the media and in fact made waves much bigger than most mods enjoy. Can you just tell us a little bit about how you first decided to undertake this project? And what you actually implemented in that mod?
PT: So I guess this will be a slightly longer answer. But I’ll try to keep it somewhat concise. So basically, Dark Souls: I was really looking forward to it. Because, first of all, I played Demon’s Souls [FromSoftware, 2009] on the PlayStation 3. I also really liked the co-op aspect of it and wanted to play it with a friend who only really plays games on PC. And since it was getting a PC port,2 that’s something I was greatly looking forward to. And then this rumor started appearing that the port would be bad. This was before release. So that it didn’t even basically let you select your rendering resolution and I, how shall I say, in the all-not-knowing youthful state, I posted on some forum: “That’s impossible. No one would do that. Why would you even do that? That’s, that, I mean, that makes no sense.”
Well, then it turns out that is actually true. Like, two weeks before release, it was confirmed that this would be the case by some reviewer, who had early access to the game. The reason I thought this wouldn’t happen is because it’s really not that difficult to render 3-D graphics at different resolutions. So I thought, “Can’t I do something about this?” In the end, the game only talks to the graphics card via the GPU [graphics processing unit], which it talks to via some API [application processing], which at that point, especially, was still DirectX 9 [and] wasn’t that complicated—there aren’t that many ways to make a frame buffer. You get your pixels, and then you render into it. And you render at the resolution you created the frame buffer.
So I thought, Hey, can’t I just get in there? Replace the calls to that DirectX DLL [dynamic link library], intercept them, get the right calls, and figure out how to increase that resolution? Since I figured out it should really work, I got really motivated to do this. And even before the game was released, I tried doing it just simply in another DirectX 9 game because I think the way they create their frame buffers or their secondary render targets and render into them is more or less the same for all of them. So I started working on it with a different game. I think it was The Witcher 2 [CD Projekt Red, 2011] at that point.
When Dark Souls was actually released, a lot of the time I spent working on this was also just working on tooling because you really had to get an idea of what the game is actually doing. So basically I had this really primitive tool (by today’s standards), which dumped the content of the frame buffer, everything the rendering steps, and that I could go through and see exactly what was happening. And I had all these tools, I had my proof of concept implementation. Then, I basically got it to work within a bit under half an hour after the game was released, and that’s one of the reasons why it is legendary. But I spent two weeks before that working on all this stuff.
I released the first version within a minute [of its completion], posted the screenshot in thirty minutes, [and] had the version that I could really settle [on], I think in an hour or so. And then I posted that, and I think also because of the timing that’s one of the reasons it blew up in the beginning.
The mod, to me, was the most important thing it ever did, as it allowed you to set the rendering resolution and then the game rendered at that resolution. After that was done, I started working on those more quality-of-life things like ambient occlusion, better shadowing, better depth of field effects, all that stuff. So try to get in the right type of the game, pick stuff out that didn’t look as great as I thought they could look and replace that. So that’s more or less how the mod evolved over time.
LB: It does still seem like as you said—it’s not that complicated in the grand scheme of things. Why do you think From[Software] or whoever implemented the PC port failed to do this in the first place?
PT: That’s a great question and it’s one that I often asked myself throughout the years of fiddling with other baffling decisions in ports. I don’t have a great answer now that I’m on the other side, basically working on ports. I have some appreciation for why other things might not happen, or happened much less frequently than I would previously have assumed. I think there really has to be something severe like, I don’t know, some lack of background or knowledge on how the PC platform really works on the part of both the people who are controlling the priorities of the port and also the people really implementing it. So that’s the only thing I can imagine if you always work for a very fixed platform like a console where everything is controlled with you, [though] even this isn’t that true today. But back then at least, where you produce exactly one version that runs exactly as you expected, as you tested it to, and you just take that mindset and put it on the PC port. That’s how I imagined that happened. But even still getting stuff to render at arbitrary resolution, so same aspect ratio, nothing has changed, but just changing the resolution really shouldn’t be an issue.
MF: [You talked about the experience with the Dark Souls mod, but] we want to know how would you define repair and maintenance, especially when you’re considering your experience that you had with Dark Souls and modding?
PT: I mean, it’s difficult. I really in principle wouldn’t classify what I did as repair or maintenance because the game that they released on PC was running exactly like the console version that they had released on PlayStation basically. It was a one-to-one thing. It wasn’t broken. So maybe calling it DSfix was in that case not the best choice of words.
I don’t really think it was fundamentally broke, that the game was broken. In my opinion, the port was broken. So it’s more of maintenance in the sense of really making it conform to the expectations you have for the particular platform, as opposed to just in general the game working as it should, in the aspects that are nontechnical and independent of the platform. So I would say I think that other mods—some very famous and well-made mods like, for example, the restoration patch for Knights of the Old Republic 2 [LucasArts, 2004]—which really go into outright fixing severe gameplay issues in the games, and I don’t think DSfix is one of them. But I think those are, of course, also very important, or even more important.
LB: Going off of that, how do you decide that a game is broken enough to merit a fix? Or is thinking about functionality in games or in software in general too complex for a binary like broken and functional to describe the whole array of states?
PT: I think there are maybe two different questions you asked me, because one of them is when is a game broken and the other one is how do I or most modders probably decide to work on it, because I think those are related. But they are absolutely not the same. Because if there’s a broken game out there but I don’t care about the game, I’m not going to start working on it. So it can be as broken as it wants. I don’t think most people are going to care if it’s a really bad game. So I think that’s this convergence, where a game has to be fundamentally great but broken or not as good as it should be in some aspect. I think that’s when you get the biggest modding scene.
And I think the two examples —we had a really great example of that. So the PC port of Dark Souls, but also just to state that Knights of the Old Republic 2 was forced to be released. In both of those examples there’s a fundamentally fantastic game there. But it’s also falling far short of its potential. So I think it’s more like, how far from the potential is it and how easy it is to, or not easy but viable to, nudge it toward that potential?
LB: So do you tend to think of potential in technical or in creative terms? Or is that also a false dichotomy?
PT: I think both exist. And I think for example, for Dark Souls, what my mod does is it helps it fulfill its technical potential on PC, and the creative potential was always there. I generally feel like that’s, again, a case of like there being different kinds of mods. There are mods that are more on the creative side, there are even total conversions and things like that. So you can basically have mods that keep the entire technical underpinnings and create a new game on top of that technology and there are mods that keep the entire creative aspects of the game and just improve the technical side of it. Then we’ll say that, perhaps even two pretty fundamental categories of modding and of course you can have mixtures between those. And I would say something like a total conversion mod like those Elder of Scrolls V: Skyrim [Bethesda, 2011] total conversions that implement an entirely different game in the same engine are one end of the spectrum, and something like DSfix is on the other end of the spectrum that’s keeping the game exactly the same, but improving the technology.
MF: So, when we talk about DSfix there’s a lot of gamers who say that these mods actually saved the Dark Souls PC port, and that it was responsible for a bump in sales and marketing. So as a modder, a professional game developer, and an academic, what role do you feel fans should play in the maintenance and repair of video games? Is there a point where fan modding actually becomes exploitation from the industry? What is your take?
PT: That’s a very good question. I think, in principle, companies should be much more proactive in maintaining their games. Obviously, I really feel like that. But I also see to some extent why that isn’t really viable at least in the case [of] boxed traditional, so not boxed, but “boxed,” in quotation marks—you have a one-off sale of a game, and then they move on to the next game. That’s how the game industry outside of service games work.
So service games are of course different. They are usually quite well maintained. But on the other hand, once the service goes out, they just go away immediately, which is also not great. But while they are ongoing, they are well maintained. That’s also because there’s a steady stream of income from that service game.
If you have something like a one-off release, which is what we are talking about with these individual releases, it’s difficult to say that the company should maintain it for a decade or two decades. And at some point, obviously, if it’s a beloved game, then some people might step in at once to maintain it.
Personally, what I feel is that companies should really just be more open to … not supporting these things, because that’s not really viable, but just not making them harder than they should be. If there’s basically not going to be any income coming from that game anyway, I feel like the responsible and correct thing to do for companies would be to make it as easy as possible for people to maintain those games by documenting the file formats or, I mean, ideally releasing the source code. That’s just very difficult today because of all the third-party components that you don’t have full control of licensing for. But I mean, John Carmack [cofounder of id Software] did this extremely well, for as long as he had full control over what’s happening. I really have to give him credit for that.
So I think saying that it’s exploitation of fans, if they do it on a completely voluntary basis ... I think it’s just not really true. I wouldn’t agree with that. I do agree that at some point what the companies are doing feels really shortsighted and also, to some extent, ungrateful. So in my personal experience, one thing that did piss me off at some point is that I was basically hosting the DSfix on my Dropbox account. I think it was at some point because I couldn’t host on the web space anymore because the transfer volume was getting too big. And it got hit with a DMCA takedown by Bandai Namco, so the publisher of Dark Souls at that point … It makes absolutely no sense. First of all, basically, if this was ever an actual legal battle, which of course didn't happen, and they also never commented on this again—it never happened again. But there was absolutely no copyright code in there—nothing was in there. So that’s the kind of thing where I say the companies should at least try to not be prohibitive about the efforts of others to make their products better, because that’s just silly. But other than that, I would say it’s difficult. There are two perspectives to it.
MF: After this ban that you got from the publisher, how did you solve the situation? Did the players upload DSfix in another Dropbox, et cetera, so it kept running? What was the end of this story?
PT: I just started basically hosting it on, what’s it called, Nexus, Nexus Mods, and that was actually the smartest decision anyway, because they are really used to this kind of stuff and they have a massive infrastructure for it. So that wasn’t a problem anymore. And, of course, the actual source code repository, because of course DSfix is completely open source, was always on GitHub, and it was never taken down or anything like that or even got any problems. So, it wasn’t a huge deal then. The only problem was that I was really using this Dropbox account for what I would call actual work stuff, like university work. So, if that account got blocked that would have been really potentially problematic and that was my biggest concern about it. But in the end, it didn’t turn out in this instance to be a big deal for DSfix.
LB: So speaking of the kind of gap, or lack of a gap, between fans and industry players—a few years after you published DSfix, you and some other modders formed a game company, PH3 GmbH, which quote “specializes in the engineering aspects of game development,” including quote “high quality ports, as well as consulting related to performance aspects, optimization parallels ... parallelization, refactoring and tuning.”3 You have since had a hand in porting or optimizing Trails of Cold Steel 1 through Trails of Cold Steel 4 [Nihon Falcom, 2013–18], Ys VIII: Lacrimosa of Dana, Ys IX: Monstrum Nox [Nihon Falcom, 2016, 2019], and Res Infinite [Enhance, 2001], right? Can you tell us a little bit about how you went from modding and your academic pursuits to industry pursuits? And how do you think the pipeline from modding to industry functions more broadly?
PT: First of all, just one correction. I did not create the company with other modders. No one else who cofounded the company with me did any game modding before they tried this company, and two of the people—so it was just three of us—and two of them had never really done anything with games before and also are big gamers. They are the people I was working with for like six years during my PhD studies. So they are high-performance computing specialists. Basically, they didn’t really do much with games before that. Since then, we’ve also hired a few people. So now our company is large—we have six people. [laughs] We’ve hired three people and all of those have a bit more, even a lot of background in games. But the original founders of the company didn’t really have a games background. Of course, high-performance computing, in terms of the actual programming you do, is one of the closest things to especially performance optimizing and porting games you can get on the fundamental level. But that is tight.
The bigger part of your question was like getting from doing this as completely as a hobby to doing it professionally. And I think the fundamental reason for that is really one particular instance, which is that Ken Berry of Exit Games sent me an email and asked me if I can help them with their port of Little King Story [2009], I think is the name of the game. Yeah, Little King Story on PC, which was really bad, and I had actually received emails like that prior to this a few times. And my answer was always the same: “Yeah, sure.” One, pay me X amount of money per hour I spend looking at this, which was actually quite low, because there was always interest in doing this. And two, of course, I need access to the source code. And the people who sent me that, for some reason, didn’t expect the access to the source code path, or I don’t know, didn’t think about this prior to Ken. They usually didn’t have a problem with the payment part. But the payment part, I didn’t want to try modding these games for the official publisher without having access to the source. This is just so fundamentally ass backward that I didn’t want to do it. So basically, what happened is that I said the same thing to Ken. And he said, “Yeah, sure. When can we start?” And then he said, basically an NDA [nondisclosure agreement] for the source code, which makes perfect sense. And I signed that and got to work looking through it.
Now, this was probably also one of the most difficult projects I ever looked at—Little King Story. In the end, what came out of this was a patch for the game. But it was far from solving all the issues that it had because this was really a game that was written in a very particular way for the very particular system it was developed for and basically it had its own custom scripting language, and all of those aspects of that came together to just build something that was made specifically to run at thirty frames per second on that particular hardware, using those particular inputs, and getting from that to anything else was really difficult.
But still, I think Ken was happy with the result of that, even though it was just a partial thing. And then he contacted me again for helping out with the Trails of Cold Steel 1 port and that was interesting, because that was a port that kind of worked, but it was much slower than it should be. And I basically presented two options: we could try to make that faster, or try to basically rewrite the entire thing, that we use a different backhand because it was using an OpenGL backhand and the engine also had a DirectX 11 backhand, but it didn’t work with that particular game. So I said, “Yeah, that should work much better once we actually get it to work but that would be a larger undertaking and I would have to spend some time on it.” So he said, “Yeah, go ahead.” And I did that. And we ended up with a port that I’m still quite happy with. But obviously, I didn’t do the entire port with that.
After doing that, Ken asked me again if we could do something similar for Trails of Cold Steel 2, and I just said, “Let me do the whole thing.” And then I basically, it seemed to make much more sense to me because I just didn’t have to step in between where we have bad port, we have a better port. But it seemed to make more sense to me. Before doing that, I would never have thought, “Hey, I can just do this port,” because I thought it was a ton of work that firstly none can do so. In this case, I also didn’t do it completely alone, I got a bit of help from a colleague who basically I subcontracted to also work with me on the Trails of Cold Steel 2 port. This was before the actual company PH3 was founded, so it was like individual contract work. And, yeah, that’s how it got started. And that’s how I got into actually working on this professionally. And after that Trails of Cold Steel 2, that was really where PH3 got funded and we started, of course, to do a lot more things. And I guess more professionally as well.
I think there was another part of the question, which is how the pipeline in general works. And I have to say, I think I’m not sure if there’s a general pipeline for this very particular thing, going from modding to actually working in the industry. I think there’s one where really, people work on mods to basically improve their portfolio and I guess to some extent I also did that. But I think my case is somewhat special in that I didn’t really actively try to get into the industry, that wasn’t my primary goal, or even, I didn’t even think about this honestly, and I was making the mods. And I’m sure it’s true also for some other people, but I also know that there are some people who really actively work on mods because they see it as a good stepping stone to get into the industry, which also makes sense. Because if you can really ship, for example, a total conversion mod with a team of other people, then you really demonstrate that you can have the skills to work on the game. So I think there’s that aspect as well.
MF: So, we find that porting and other maintenance and repair practices, at least on PH3’s websites, are often ignored by fans and academics alike. Because, we would argue, maintenance and repair are considered a technical craft in comparison to the creative work like writing, art, or design of a game. So what forms of creativity do you find in the work that you do? And do you feel that it has ever been devalued or overlooked because of its purely technical orientation?
PT: Oh, well, yeah, that’s … again I really like these questions, because these are like aspects that I don’t think about a lot. There’s a lot of creative work that goes into what we do. On the one hand, just the general creativity that goes into all programming work, which is, I think, something that’s generally vastly underrated because, of course, programming is engineering. But also, how shall I say, I also work a lot with students and teach them programming and stuff like that. So I think I’ve a somewhat broad perspective of this and they are … I don’t know if it’s just practice, but I feel like there’s a lot of creative leaps you have to take when programming and it’s a fundamental difference between really good programmers and well, average programmers or something like that.
It really manifests to a massive extent in terms of the time you have to spend to solve some issue, especially if it’s an issue in a really large code base that like in the porting context, where you are not really the author, or you haven’t worked with this before, getting from a reported problem or something you want to do to where and how you actually do that, in that large code base is, I would say at least is as much an intuitive and creative process as it is an engineering process. How you then actually implement this is of course engineering, but just ... how should I describe this? Like, the pure engineering approach to this would be something like bottom-up where you have to understand the entire thing, and then engineer the solution to whatever you’re doing. But that’s not something you can do, at least in my experience, when you’re actually doing a port, because the entire thing is 1.5 million lines of code. You’re never going to even see half of that while you’re working on the port. You have to just as quickly as possible grasp the essential underpinnings of it and work with that and that’s already in my opinion a somewhat creative process. Of course, that’s one aspect of it.
The other aspect I think [that] comes with [these] things that in the entire context of the game might be relatively minor, but I think still make a huge difference to the actual players of the game. Like how do you, for example, implement mouse keyboard controls for a game that was originally designed to be interacted purely with the controller? That's depending on how much and how well you want to do this because of course many games just do the absolute minimum and they don't play well. But depending on how well you want to do this, it basically requires rethinking how the player should interact with that game ideally, and how you implement that. So I think there’s also some creativity in that aspect. So in how you transport the original idea to a different input output mechanism.
LB: So this is a strange question perhaps, but it’s one that I’ve been thinking about a lot as we’ve been working on this special issue and talking to our authors and thinking about these interviews. Which is, what do you think is the relation between maintenance and repair work in software like this? Porting, as you said on one hand, ports themselves can be broken on their own terms, but they can also be broken in that they don’t live up to the potential, I think was the word you used, of the original game? So how do you view this relationship between maintenance and repair and porting? Is porting or can porting be a form of maintenance and repair? Or do you think that they’re very discrete, and why or why not?
PT: I think they are not discrete. At least on the spectrum, they are not necessarily the same thing but the initial port might be a bit further away from maintenance, of course, but then there’s also maintaining the port. And also, for service games in particular, there’s, like, the challenge of keeping all the different versions in sync after they’ve been ported, which is an additional challenge. But in general, I would say porting is maintenance plus the creation of individual aspects of the game, the re-creation of them in a suitable way for a different platform. In particular, this example I brought up of the input would be a great example. That’s something where you have to have an initial vision for the port and implement that. And then there are other things like, for example, performance optimization, which is more of a maintenance thing. You could also optimize the performance of the original platform, probably in similar ways. And those I would classify, of course you have to do them in the context of a port for a different hardware platform. But I would still say that’s not fundamentally different from what people do with a normal maintenance scheme.
So there are those individual aspects where in some way the platform really is very different from the original one and where you have to make an actual creative choice, and others which are more maintenance focused. A different example would be if you were porting a game, a modern game to like a really low-spec platform, where you really have to make decisions on for example, you might have to split the memory into many parts, because you simply cannot fit it all in memory, that would again be more than just maintenance. People have to make a new decision and make actual changes to the game. So it also depends on how dissimilar the platforms are. I would say things like porting from a high-end console to another high-end console. It’s mostly like maintenance work, because you are not really dealing with fundamentally different inputs, you’re not dealing with a fundamentally different situation in how the people play the game. Both of them run it on a similar platform sitting in front of a TV screen. There’s a lot of technical work involved, but not really anything fundamentally changing.
LB: So going back to an earlier question, in light of your response here: you think of maintenance, software maintenance, and game maintenance as being almost purely technical. And when it becomes less technical, it becomes something else. Is that a fair characterization?
PT: I would say so, yes. From my perspective.
MF: Are there any other aspects of the work that you and your peers conduct that fall under that classification of maintenance and repair that we haven’t talked [about] here?
PT: Well, maybe not. I wouldn’t say other aspects. But I think since you’re focusing on this aspect, what might be interesting to you is like, the professional setting, the constraints that you’re working under when doing this because I mean, we try for the games that we’ve professionally released to really keep up the maintenance but simply the challenging aspects of like trying to just release a small patch for a game that you last worked on two years ago really cannot be underestimated.
So like we have in our list that probably the rest of my company is right now going through, because that’s what we do in these meetings, we have entries for patching games that are now released three years ago or something like that, where we have really, really minor things that we already did, [and] we just have to release them. And even when you do a really good job in trying to automate all of your releases and build processes and so on … It’s still not trivial, especially for a small company. I assume, if you have a thousand people, it’s different. But it’s just not easy to get those changes actually out to people. And it gets enormously harder if the game is on consoles, than if it is on PC. So it’s just trying to maintain games as a company is really, as a small company, particularly, it’s really not easy.
To some extent, like patching, my mods were incredibly much easier than trying to make an official patch for a game, not in terms of the technical aspect, because doing the work in the source code is obviously trivial compared to doing a mod, but just in how you get it out to people. And in a mod, basically, if you just break something, no one is really going to be that angry as soon as you just unbreak it again like two hours later [since] everyone expects that with a mod. Obviously, with the game, you can’t do that. Or similarly, I mean that when I’m writing my mod I’ll just throw up some lines of text to describe what I did. If your game is out in n languages, then your patch notes have to be translated in n languages so that they have to be signed off by the publisher. None of this should ever be construed that I’m complaining about the publishers we’re working with—they are great—it’s just that these are the constraints that just occur when you transition from this modding model, from this hobbyist model to a professional model, and they are almost unavoidable.
LB: How do you think that maintenance and repair practices have informed the history of video games? Again, the entire premise of this issue is that things like keeping servers running—maintenance or repair work is typically invisible. We don’t ... even historians don’t really think to talk about it. And so are there examples of maintenance and repair in game history that you think are really significant that people don’t really pay attention to?
PT: I think that what you’re fully covering already is like this transition from one of shipped games that cover the cartridge to digitally distributed games, where you have a much easier time patching them, and then finally, to service games, where maintaining them, at least during the service period is a much bigger deal than it ever was. So I think, in addition to that, what happened recently, or relatively recently, is that people start to see value again in really old games, in rereleasing them, so value not just in the creative sense, of course, there was always value there, but monetary value in rereleasing them or in trying to revive those games in other ways. And I feel like that really cuts both ways and that’s, in some respects, even problematic. And in other aspects, great, of course, because it’s great when the company does a good job, in terms of porting the game to modern platforms and doing all that maintenance work, and that it’s fine if they also like charge something for it.
But the other thing that happens because I think they are starting to see more value in those old games, again, is that they really prohibit any efforts by other people or by modders or just archives in keeping those games around. And for a while no one cared about them. And that was bad on the one hand, but good on the other hand, because at least the people who actually did care about them weren’t prevented in doing so by companies because they just didn’t see the value in those old games anyway. Now if they do that again, it also becomes harder to maintain it. So basically, companies trying to revive their old games is a great thing if they actually do a good job of it and stick with it. But it’s like worse than doing nothing if they just half ass that entire aspect. So, so that thing. That’s one thing I’ve noticed somewhat recently with the development about putting more value into these older games again.
LB: All right. Well, Mr. Thoman, thank you so much for this interview. This was a really fantastic informative interview. I appreciate you taking the time.
PT: Thank you. It was really interesting to me as well.