EPISODE 1783

[INTRO]

[0:00:00] ANNOUNCER: Video game emulation is the process of using software to replicate the functionality of gaming hardware. It's a fundamental approach to making older games accessible on modern devices. The Carbon Engine is a tool developed internally at video game publisher and distributor, Limited Run Games. It allows a variety of emulators to interface with modern video game hardware, and it supports emulation of SNES, Genesis, PlayStation, Game Boy Advance, and other consoles.

Dimitris Giannakis is the lead developer of the The Carbon Engine. He has known for his many contributions in the hacking, emulation, and game development space and for his highly popular YouTube channel, Modern Vintage Gamer or MBG. Dimitris joins the podcast with Joe Nash to talk about how he got started in game development, building emulators from scratch, scoping an emulation project, homebrew versus official SDKs, The Carbon Engine, and more.

Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got a start in software development by creating mods and running servers for Garry's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

[EPISODE]

[0:01:29] JN: Welcome to Software Engineering Daily. I'm your host for today's episode, Joe Nash. Today, I'm joined by Dimitris, otherwise known as Modern Vintage Gamer. Lead Developer of Limited Run Games' Carbon Engine. Welcome to the show, Dimitris. How are you doing today?

[0:01:41] DG: I'm doing great, Joe. Thanks for having me on. It's a pleasure to be here.

[0:01:45] JN: Well, so today, as I mentioned, we're here to talk about the Carbon Engine. But before we get into that, your path to Limited Run Games into The Carbon Engine is really interesting. Can you just tell us a little bit about what led you to where you are today?

[0:01:56] DG: Yes, it's a really interesting question to ask. There's so many different ways to kind of get yourself into the game industry. Some people do the academic route where they go to school and learn game design concepts and game programming. I did some of that. I mean, I went to college. I did a computer science degree, but I didn't really go by traditional means. I kind of went in via, I guess you could say hacking and modding.

Basically, the way that I kind of got my foot in the door was during the early 2000s when game consoles were becoming powerful enough to start to run homebrew on predominantly systems like the Dreamcast and the original Xbox. I found that there was a really interesting underground scene where people were kind of building emulators and applications and video players and MP3 players, an unofficial capacity, right? I was very fascinated by this. The system that really kind of kickstarted the whole thing was the original Xbox.

So, my kind of way into the industry was predominantly by just messing around with game consoles, hacking them, building homebrew for them, or porting emulators and getting experience in these systems outside of official means. I think after that period, I started to get more focused on making YouTube videos as well because I thought that at the time it wasn't really - no one was really covering that kind of stuff on YouTube. No one was really covering the underground homebrew scenes and the areas that I had a lot of experience and familiarity with. So, I thought, "I'm going to cover this stuff." If not for anything else, just to almost keep a personal diary of some of the things that I've done in the past.

It wasn't really until one particular video that I made that got me recognized by Limited Run and that was, I ended up actually porting Diablo, the original Diablo onto the Nintendo Switch in a homebrew capacity. So, it was completely unofficial, completely, I guess you could say illegal if we take Nintendo's stance on this. It got picked up by a lot of articles, publications like Kotaku, IGN, and various other articles had kind of made this big post about a developer has ported Diablo to the Switch.

That's what ultimately got me recognized by Limited Run. They reached out to me and it was back in, I think it was back in 2018, 2019, around that time. And they reached out and said, "You obviously are a very experienced. You know what you're doing. Would you be it in coming on board. We've got an exciting new project that we're trying to spin up here, and that's kind of reintroducing old retro games to a modern audience." That sounded exactly like something that was up my alley, and I guess that's how it all started.

[0:04:49] JN: Perfect. Amazing. Yes. I mean, what you said about the YouTube channel at least functioning as a diary thing is really interesting. Well, because I think one of the things about the homebrew scene and stuff you're working on is understandably given the legal aspects. A lot of that information, like if you're not at the time and place when the hack happens or when the port happens, it's very easy for that how it works and that to go completely missing. Your channel, I think, it's been a fantastic resource for like actually getting an idea of what's possible and what's happening out there. But the technical detail you go into in some of your videos is really fantastic.

So yes, I mean, from someone interested in the scene, big thank you for putting that resource together. But I guess on to that project working on now. I guess the best place to start is Carbon Engine being a title on the word will put people in mind of things like Unity and Unreal is like single tools for developing a game. And Carbon Engine is a little bit different, right? My kind of impression of it is it's a wrapper around a bunch of emulators and tools for working with ROMs without source code. Is that accurate? How would you describe it?

[0:05:44] DG: That's a pretty good way to describe it. There's a little bit more nuance to that. I would say there's obviously, Basically, you could say that it is that, but there's also a lot more functionality around it. It has to do with the various aspects of a good or modern game console design. So, there's also additional functionality in place, for example, things like trophies and achievements, the various controller functionality that we support. So, anything that has to do with the modern console experience also features those things, the social aspects as well.

But yes, I mean, you could say at a high level, it's definitely it's software that kind of encapsulates emulation. That's a good way to put it, for sure.

[0:06:31] JN: It's a really fascinating approach. I mean, A, because I feel like I say this every time, we cover a lot about what a nightmare porting is on this show. As you're doing that, without access to source codes, which was fantastic, but then watching some of the videos that Limited want to put out and that you have put out about how you're able to add to the features like achievements and change you wise like, Shantae for example, with just like hacking into memory and you're making tooling around that. Super, super interesting.

I guess to start with, I want to talk about the emulators because I think one of the things that was surprising, tell me about the emulators that you currently support that built into it. Because there's a mix of emulators that you've built yourself and open -

[0:07:07] DG: And licensed. Yes. So, it all kind of started when we first signed Shantae and that was the kind of the original Carbon Engine release. So, at the time, when I first came on board, Limited Run asked, is it easier just to build our own? Or is it just easier to license? I really wanted to build our own Game Boy Color engine for this. But since then, we've added NES, Super NES, PlayStation. Believe it or not, we've done Spectrum as well. And fun fact, the Spectrum engine is actually being used by Digital Eclipse in the Jeff Minter Collection.

So, if you're familiar with the Minter Collection on the Digital Eclipse stuff, if you fire up the early Jeff Minter games that run on the Spectrum, or a ZX81, I think, as well, that's all stuff we've built as well. So, we have that. We've also done Genesis, Mega Drive, Game Boy Advance. I think that's it. I think that's all that we have. I may have missed one, actually, now that I think about it, but it's a combination of licensed emulation and homegrown stuff. I think the choice is pretty simple and that is how long is it going to take us to build something versus just to license an open-source emulation product out there. 

For Game Boy, I think that's something that for me, I wanted to take on the challenge of building my own emulator from scratch because I've done a lot of porting work over the years, but I've never actually sat down and just open a new project in Visual Studio and started coding one. So, I basically told LRG, "Look, I think I can build one in about six months," and we were able to accomplish that. For Nintendo, we did the same thing. We built our own engine from scratch. And the great thing about building emulators, like, you know, those old, early eight-bit emulators is that there's so much documentation and information out there. There is an amazing emulation community that really can help you along the way.

So, it doesn't matter if you're doing it in a commercial sense or if you're doing it in a hobbyist sense. There is so much really good information, solid information out there. But yes, I mean, it's really just a, I
guess a mix of in-house develop stuff and license stuff. Like PlayStation 1, for example, there's really no point for us to build our own PS1 engine. It would probably take us about two to three years and there's already some great, some fantastic PS1 solutions out there. So, it's just an easier conversation just to chat with the original developers, get the approval, license the emulation and then just go from there.

[0:09:49] JN: Awesome. So, when you talk about the community support and the resource community out there, I think one of the things that really surprised me about the video in your Game Boy build was the test cartridges. Can you talk about that briefly?

[0:10:00] DG: Yes. So, with Game Boy, and there are definitely other platforms that have very similar tools, but Game Boy is one such piece of hardware where developers, homebrew developers have built test cartridges that all they do is literally go through all the different facets of the hardware and kind of compare it against your emulation. And it will tell you if you have any kind of specific errors along the way.

So, there is one particular cartridge that, it's a ROM basically, that tests every CPU opcode in the Game Boy, which is a variant of what's the Z80. It's the sharp processor, which is the variant of the Z80. So, it will test every single instruction for you, right? It will just perform simple instructions for you. So, there'll be like a load instruction, a store instruction, things like that. So, it'll branch the instructions. It'll basically just run through the gambit of all the different tests and it will tell you, did you pass this one? Did you fail? Those types of things are really useful because if your emulation has some type of issue where you are playing games and you don't really know exactly what's going on. It's always good to run these test cartridges just to kind of verify that, "Hey, my CPU instructions, they're all good, they're all accurate." But there's also cartridges that also test things like the V-blank timings, the PPU timings, the sound accuracy. There's all these tests that you can run.

And I will say that there's probably only maybe one or two Game Boy emulators out there that can basically pass the entire suite of tests. And getting to that point is obviously something that, everyone that's developing emulators wants to get to, but I found these tools very, very useful to basically get the appropriate accuracy and the level of compatibility that we were looking for.

[0:11:59] JN: Yes. So, there's one thing that I was wondering when, given that the first project was like, with respect Shantae, you knew what game you were going to be building for. When you were building out that first emulator,11 were you targeting the features that you need, were there things that you left for future titles, being like, "That's not worth dealing with in detail right now. I'll come back to it," or were you aiming for a general platform from the get-go?

[0:12:18] DG: So, the way that we kind of do things is the focus really is about the game itself. It's a good question too, because if you are familiar with the Game Boy, the cartridges, there's different what they call MMC chips or they're basically mapper chips, right? So, in the sense of, in the example of Shantae, there's no reason to build the other mappers out if we're only focusing on Shantae, which is I believe it's MMC five, I think it's an MMC five mapper. So, there's no point building the other MMC chips if we're just focusing on this.

The way we kind of work is we just kind of build feature sets as we need them, right? In the case of Shantae, the first, it was kind of an iterative process when we started building the emulator because as I was building the emulator, I was still learning about the Game Boy hardware. I kind of took a very iterative approach and just kind of had a couple of milestones in mind. The first one was just getting the Nintendo logo scroll down the screen, like the initial kind of power on. That was kind of step one. Then step two was getting a simple game like Tetris to boot up, which has nothing to do with Shantae. And obviously, it's not Game Boy Color at that point, it's just original Game Boy.

But Game Boy Color, the editions of Game Boy Color kind of adds on top of the Game Boy code anyway. So, it was really a matter of just getting some small steps in place, kind of proving out that we could do this. And then once we had something up and running, we had original kind of DMG Game Boy running. That's when we started adding the Game Boy color enhancements to the engine. And that's when we really start to focus on Shantae itself.

So, everything else outside of Shantae wasn't really considered at that point. But we have since added more Game Boy Color games to The Carbon Engine. In the case of that, if there's a different mapper chip or if there's different functionality that we're not using, then we basically just go back and add those things as we need.

Now, in the case of licensed emulation, usually most of those things are already done for you because they've already built out so many different features, it's not really a case of going back and adding more things. But in the case of our in-house develop stuff, as we get new projects, assign new projects, if there's functionality or if there's some piece of hardware that we're not emulating properly, then we're going to go back and add that in.

[0:14:46] JN: Right, that makes sense. Beyond the emulator, what is the functionality that Carbon Engine is providing to developers? What kind of tooling have you built out to help your porting work?

[0:14:56] DG: It's basically a very rapid tool to spin up new games very quickly. We have it not only for developers, but we also use it when we want to do some demos at trade shows like GDC, DICE, and things like that. Every year, we obviously want to sign up more of our partners and bring their all games back. We have a solution for them, right?

So basically, it's all pretty much internal stuff. It's not really an outward-facing product, but it's a very, very easy thing for us to say, "Hey, we've signed, or we're potentially going to sign this new deal. Let's spin up a demo with some nice looking front-end and some functionality in place and the game itself and maybe a couple of features here and there, and then just present that to our partner and see what they think about."

It's really very, very easy to kind of spin up something very quickly that we could offer our partners and show them and have them take a look at.

[0:15:59] JN: Awesome. So, it's like a smorgasbord of things that blew my mind. That's all about this. So, I guess to focus on Shantae. In Shantae, you were doing various things like changing UI, swapping the button controls. I think some other tiles that changes you made, and I think I meant, so you mentioned at one point that you had localized various games. But the context for what is in mind, is a lot of these cases, you're not doing that on the source code, you're doing that in memory. What kind of tooling are you building to support doing that quickly, as you say? Because that seems normally understanding a game's memory layout and editing is a laborious process.

[0:16:33] DG: So, there's a couple of different ways we approach. I'll just use the word ROM hacking, because that's what we're doing. There's two ways that we do it and there's really no set method, whatever kind of makes more sense. Sometimes it's a matter of just going in and editing the ROM itself directly. So, for example, one of the things that we have to do is remove any old licensing information from the game. When you plug in a Game Boy game or a Super NES game, the first thing you're going to see is licensed by Nintendo on the screen.

Obviously, because that does not apply, we have to remove any kind of old Nintendo branding. It's a matter of at that point, are we literally just hex editing or tile swapping out those tiles? Or are we doing it dynamically in code, right? There's really no one set answer to how we approach it. It really just depends on the game itself. Some games have a little bit more sophistication as far as things like protection and compression. Some games have some custom compression that we're not really familiar with. So, it's just so much easier just to say, "Right, we're going to just get the debugger out," and we know that the license screen gets hit here, so we're just basically going to patch out information on the fly.

There's really no set kind of way that we do it. We kind of just approach it in different ways. But on our team, we have some really experienced people that have been around emulation for many, many years. You probably know one of them. You spoke to him recently on the channel.

[0:18:03] JN: Yes, we've had Randy Linden on.

[0:18:05] DG: So, between the three or four of us, we usually figure out a way to get things done. I think that's the best way. But we use things like Lua scripts to kind of intercept. We do our own custom interception handlers as well. We do ROM hacking. It really just depends on what is the most sensible approach to get things done.

[0:18:23] JN: Yes, I mean the interception I guess that was another area that I think is really interesting. So, I guess the interception comes into play when you add your same things like achievements. You're looking for specific bits of memory being set and then triggering achievements. How does that work in terms of the - I guess, what is the distributable here? There's obviously some binary that contains the emulator and then a bunch of scripts on top, and then that's ported for the platforms. What does that look like?

[0:18:48] DG: Yes. It's all C++ code. It's not really scripts that we use. So, we're predominantly just build things using C++. But we have, without getting too kind of, I don't want to talk about specifics about what we do, but we basically have the engine, the emulation engine itself. Then on top of that sits kind of the game handler. And that game handler just basically handles all the specific aspects of that game. So, it'll manage the achievement, the trophy handle as far as, it'll manage any type of patches that we need to do on the fly. It'll manage the social part of a game console. For example, what users currently signed in. It'll manage the number of controllers that are connected up. If the game's two player or versus one-player, things like that.

That's kind of how we do it. We don't really use kind of scripting in a traditional sense. There's no like dot txt file that tells the engine to do all this sort of stuff. We just kind of do it ourselves in C++. 

[0:19:46] JN: Awesome. And then in terms of platforms, I know for some games, you're targeting specific platforms. Obviously, Shantae was looking for a Switch release, but you've released games now on a number of platforms, right?

[0:19:55] DG: Yes. So, The Carbon Engine itself runs on everything. Initially, we built it for the Switch because, again, we started out, we had signed a deal with WayForward to bring Shantae to the Nintendo Switch, the original Game Boy Color version back for the Switch. But since then, we did River City Girls, Zero, and that was pretty much to everything. I think we released it on all platforms, including Steam and Xbox. We quickly we had to kind of make sure that the engine was portable and kind of up to date everywhere. So, we did spend a little bit of time after the launch of Shantae to just get the engine running everywhere, right? Since then, obviously we've seen systems come out like the PlayStation 5, the Xbox series. We keep updating and making sure that the engine is running and available everywhere.

Now, the choice of what systems that the engine is running on, it's really up to our partners what they want. It's not really up to us. We have the engine running everywhere. If they tell us we want this on PS4, PS5, Xbox, and Steam, then that's what we're going to do. We can facilitate that. But a lot of the times they'll say, this is Switch only, or this is Switch and PlayStation only. Sometimes they'll tell us this will run on Steam. Sometimes they'll tell us it won't. We don't get to make those decisions. It's really up our partners on that one.

[0:21:16] JN: Right. Yes, that makes sense. The emulators is what I'm interested here. So, you've got these emulators running on all these platforms. Have you had to port a licensed emulator? Because I imagine the emulators don't run on all the - they don't have access to the official SDKs, right? What's that experience been like?

[0:21:30] DG: It's not too bad. I think, again, we've got some really smart people on our team that understand C++ and they've done a lot of porting work over the years. I'm someone that is very experienced in porting. I've been doing it, like I said, since the homebrew days on the original Xbox and the Dreamcast back in the early 2000s. So, it's not really that daunting for me, getting a license emulator and porting it to consoles everywhere. I mean, there's definitely some work and there's definitely some things that you need to do. But at the end of the day, if it's running a graphics API like OpenGL, that something like the Xbox doesn't understand because it's DirectX-based and the PlayStation has no knowledge of what OpenGL is, getting those things running on those platforms. There's a little extra work that's involved, but I wouldn't say it's anything that's too difficult to do if you are experienced with porting code, I would say.

[0:22:24] JN: Right. Yes, that makes sense. Then, I guess that's an interesting aspect. I think I saw you comment on all new videos that you've done all this porting work for years and years and years in the community toolset, in the unofficial tool set. Now, you've got access to, I imagine at this point, is every official SDK under the sun, which I know there's limitations and what can be said about that for the NDAs, for the platforms, et cetera. But how has that been as a transition? I guess as a developer, what is your impression of the official toolsets versus the community tools you used to?

[0:22:52] DG: That is a great question to ask. I will say that the homebrew community or the unofficial or the hobbyist SDKs that are out there, most of them are very, very well put together. I think the only thing that makes them not as good is, and it's not really the fault of the SDKs themselves, is that things like remote debugging, those types of features aren't available because that's when you really need official SDK to connect up your dev kit tool and do it that way.

But a great example is we talked about the start how was an unofficial Nintendo Switch port of Diablo. So, I used the homebrew Switch SDK, which is called libnx, I think it is or lib - I think it's libnx. When I actually got my hands on a Switch dev kit and I started working in official capacity, it was pretty easy. It was very, very seamless. I didn't feel like I had to start over again, start learning things again. The way things were done were kind of the same. And it was just kind of very organic and very natural for me to move from a homebrew unofficial SDK to an official one. In some areas, I will say that the homebrew SDKs offer some more functionality over the commercial ones.

I shouldn't say any anymore because I may get in trouble, but there's been a lot of work put into this stuff, and you can really tell that the community does really care about this stuff. I think, for me, it wasn't really something that I got blocked on at all. It was pretty easy and pretty seamless to get things moved across.

[0:24:27] JN: That's awesome. I guess, I imagine the answer is no, but like, is there ever a point where you reach for our homebrew now? Is that even allowed on certification or does everything have to be on their official SDK?

[0:24:39] DG: Everything has to be on the official SDK only because I believe there are certain rules around code signing and things like that. I do have a friend of mine, this is a side tangent, but I had a friend of mine that actually used to work making games on the PSP. Sony PSP, this has gone back years ago, and he actually used a homebrew unofficial SDK and published a game with that. So, I think things have changed a lot since then. But yes, I mean, I would say that there's probably no way you could do that anymore. But I haven't really tested the waters either, but it's an interesting
question for sure.

[0:25:19] JN: Yes, absolutely. So, we're talking about various ways that you modify the ROMs from outside. Has there been anything that you've wanted to do add to a game that you've struggled to do in that approach and have you investigated things like reverse engineering for any of the games you're looking at?

[0:25:39] DG: Yes. So, reverse engineering is something that we do as well and we're getting more into, because we're starting to now look at PlayStation 1 games. I think there's a different mindset when it comes to bringing back all PS1 games and a lot of the times people want to see some enhancements, including things like widescreen support on games that never had it.

Some of the things that we are looking at would be enhancing the games because predominantly all the ones that that we look at are all games that that right at 4:3 aspect ratios, right? So, adding 16:9, it's very difficult in a lot of scenarios to do that because even though you may be able to get something that does run in 16:9, there's always going to be some menu or some font or some issue where something is not right, something is not aligned properly, or there's just some overarching glitch on the screen that you can't really say, "Look, we can ship this the way it is."

So, a great example is Tomba! that we recently released the special edition. So, Tomba! is a PS1 game that we released earlier this year in August and a lot of people were confused as to why we didn't add widescreen support. We'd heard some stories about how some community people had enhanced it with widescreen and we took a look at it and we did actually quite a lot of reverse engineering on it. We were able to get the game running in widescreen, but there's just that occasional frustum clipping issue where something just magically just disappears off the screen, on the left or the right-hand side, outside of the typical 4:3 viewport. We just said, "Look, we can't do this. It's close, but it's not good enough. And if it's not good enough, you can't really ship a product, a commercial product with something that's a little bit off."

In that aspect, we just have to say, "Look, we can't do this." But we are doing more work, more reverse engineering on things like enhancing the game with widescreen. The other thing that we have done is Trip World DX was a game that was originally just a Game Boy, original Game Boy DMG game. We did a full-color translation of that. So, we brought a completely new color palette to the game, which, by the way, was something that the original author had in mind for the game, so we were able to get kind of the color values from the original developer of the game. With his blessing, we were able to do a full-color version of it.

So, we definitely do a lot of that enhancement work as well. Look, sometimes, it does pay dividends. Sometimes we kind of go down this path and take a look at things, but we just ultimately, we have to stop.

[0:28:21] JN: Yes. That's such a cool game, the original color palette from the author who didn't get to publish it and being able to do that is awesome. I guess that brings to mind the question of, I imagine when you first sign a new client for a game, there's an element of, okay, the start of this project is going to be some investigation work. We're going to work out what assets are there. We're going to be asking them to dredge the vaults. How does that usually play out? Do people come to you with like, we know what we've got for this game or have you end up having to get people go through like, obscure filing cabinets somewhere in Japan?

[0:28:47] DG: Yes. So, I think the latter. Now, I will say that I'm not the person that is involved in most of that stuff. That would be our producer, Audi Sorlie. You may know who Audi is. He's awesome. He's been around video games for a long time, knows a lot of people and very well connected with many other people in the industry. So, usually we basically just ask, we'll just ask for it. What do you have? What's available to us? You'd be surprised.

When we did Tomba! for example, we got a couple of CDs worth of just archival material, and a lot of that ends up in our museum area in our games. So, most of our games will have a museum section where we will produce things like key artwork, prototype drawings, all sorts of things, design documents, level design documents, old video clips, and archive material, anything that we think is interesting will make available. So, most of our games that we have, it's not just about the game itself, we also have just this kind of museum piece where we really want to offer as much as we can that we've dug up from the archives and make that available to our fans.

[0:29:55] JN: Awesome, yes, that's really - I think I saw the artboard for Shantae. It was a good example of that. Cool. So, I think that covers most of the things I want to ask about Carbon. You mentioned earlier it's mostly the internal project. So, I guess from a - internal tools always fascinate me from a developer experience perspective because it's so - can we tell you so much for your own needs? So, I guess to start with, will this be an internal project forever? Is this something you see Limited Run licensing to other archivists or other companies that want to preserve their old games or anything like that? Is this something you see as releasing as a product at some point you described as a product earlier?

[0:30:31] DG: Yes. I don't think we've ruled it out. I think there's been some talk about maybe making this, opening the face of this product outward-facing and making it available. I don't think, really, we're given it too much thought other than it would be something that we're thinking about doing in the future. At this point, we're just kind of heads down. We have a lot of projects going on, basically taking us throughout the end of 2026. So, it's really a matter of putting our heads above water and thinking about what we do with this, right? But I wouldn't rule it out. I think there's been some talk about maybe making it available in the future. But at this point, we're kind of just focused on getting games done.

[0:31:11] JN: Yes, absolutely. Cool. So, that leads me on to, I guess, and again, this might be me asking very particular asking very particular questions that are outside your warehouse. In terms of the Limited Run made a splash about the carbon engine and its existence, you've spoken about it, there was a podcast launched, et cetera, having the public face of it. Is that from a business perspective that's letting your potential partners know that you have this technology to resurrect their old games? Is that what the aim is?

[0:31:35] DG: Yes, that would be one pillar of it. I think the other thing is that when you think about Limited Run Games, most people think about physical products. Limited Run Games, they open up a pre-order for a game, it's open for two weeks and all that stuff, right? So, every week we have new physical products that we sell. I think the point of the Carbon cast that you mentioned and the marketing around the Carbon Engine is also to let not only know that, "Hey, we have a product for you guys," but also to let just people in general, our customers know our audience, our fans, our followers know that look, we're not just a company that does physical products. We also have internal development that we do. We make our own - we make games, we bring back old games. We have technology to do that.

So, I think that's another aspect of this where, a lot of people, like I said, they just think that Limited Run is just a company that just makes physical products, and we do a lot more of them that. I think the Carbon Engine around that is part of that.

[0:32:39] JN: Yes, that widening what Limited Run Games means. I think it's very different, as a point, I think it's something that when speaking to Randy and like watching your video about starting to work at Limited Run Games, it really seemed that there was an element of I don't say opportunity, because that sounds like that -obviously, you're both enormously skilled individuals that Limited Run Games is very lucky to work with. But I like the grassroots nature of how they found you both, how they reached out to you, and how you're doing exactly the thing that we're doing. We're looking to build out in that direction. That seems like another positive aspect that people that are hiring is an interesting way to build out that brand.

So, one thing I did forget to ask about in terms of Carbon Engine was the testing. You've mentioned the testing of the emulators. How do you go about testing the actual games that have been built on the system?

[0:33:26] DG: So, normally what we do is we'll have at least a few people on the team. We have a QA department as well, obviously, and they will usually run through the games even before it's being built out. So, as we're kind of developing, getting the game running on our engine and making sure that's running on all our platforms, we'll have our team basically run through the game, just get familiar with them. I like to do it myself as well, if I have time. So, that's kind of how we approach it. We kind of get really kind of intimately familiar with the game. We'll also look at let's plays and long plays of videos. We'll also tap people in the community that are familiar with the games and ask them about it. Sometimes we'll bring people in on a contract basis that are familiar with the game to help us out with some aspects of the game as well.

We kind of really kind of just learn as much about the games that we're doing before we really start to QA them from a testing perspective. Just so we know that if there is a soft lock in the game, because a lot of these games, you remember they released in the 90s, some of them in the early 2000s, some of these games, they had one shot, they got pressed onto cartridge and there was never a patch or an update. Some games have the luxury of like a 1.1 version on a cartridge or a 1.2.

As the customer, you don't really know, you just got a cartridge in your hand, right? You're not really sure what you have. But sometimes some of these games will have an odd bug or a soft lock or a quirk about them. So, we want to identify what they are. Some instances, we actually can work around them. We can patch around those things, if we know what they are. Sometimes we can't, right? So, we want to be sure that our engine itself isn't introducing any type of issue, or if this is something that happened on the original hardware.

We found a couple of things, talking about Shantae again, we found a couple of areas where there is some kind of glitchy soft locks and quirks about that game. I remember when we were testing the game, it came up a few times and I remember thinking to myself, "How is this happening?" Because, again, going back to those test ROMs I was talking about, all the CPU instructions are checking out, all the timings are checking out, everything seems to be good, so why is this happening? I remember just firing up the original game and playing through it and being able to recreate it. I was like, "Well, this is happening on original hardware."

So, we want to make sure that we know as much about before we start the QA process because there are things that we obviously we introduce during the emulation side, but we just want to make sure that if it's not us, then it's the original game. If it's the original game, then we'll try to fix it. Sometimes you can't fix it, which is difficult. But I think a lot of people that buy our products have nostalgia for the original games anyway. So, a lot of them are already familiar with some of these things. I think It's just a matter of identifying them, documenting them, fixing them if possible. If we can't, then at least we leave it exactly how it was so we don't introduce anything new.

[0:36:26] JN: You mentioned people look back from the nostalgia and obviously there's a certain, to a certain extent, there's like an archival value to these games. When you do add enhancements or you fix those bugs, how do you approach positioning that versus the original? I know there's like some of your launches, you have like different versions available. Do you like release like, "Hey, this is the broken one. Here's our enhanced one in the same launcher."

[0:36:52] DG: No. We don't normally do that. The way that we kind of approach it is, we have a toggle, right? We have switches to go back and forth. So, one great example of enhancing a game is Tomba! We added a remastered soundtrack to that game, which I will tell you was a lot more difficult than what it looks like. It's not just a matter of replacing this sound file with this sound file because the PlayStation, everything is the sound processing on the original game didn't use XA audio, didn't use Redbook audio. It just basically used streamed PCM audio going in.

So, we had to be very us about identifying when sound is initialized, when music is stopped, when music is started, when cutscenes play, we have to stop music. All these scenarios you could possibly
think of. In those scenarios, we basically have an option screen where we can say, "Look, do you want the original or do you want the remastered?" Another game that I recall that we did something similar to was Jurassic Park, the Jurassic Park collection. We had kind of options to go to the original look.

For the Super NES game we had a blended mode where it - because if you look at the original game, on a CRT, the game looks really, really nice. But on an LCD display, it looks a little bit pixelated and a little bit too blocky. So, we have what we call a blended mode where it basically just blends, it's not like a shader, like a high-quality sharpening or anything like that, but basically it just takes the different layers of the Super NES and kind of just blends it all together to give it more of a CRT look and it looks a lot cleaner.

I think the answer is really we just, where we can, we basically try to offer the original experience and the enhanced experience and let you go back and forth. Trip World is another one. I mentioned the full-color kind of update we did, the DX version, but we still have the original version in there as well, just in case people don't like the full-color version, they prefer the original. So, really just kind of give our customers the option to go back and forth.

[0:38:57] JN: Awesome, yes, that makes a lot of sense. Cool. So, I guess as we get close to time, one of the other things that, as we spoke about your particular journey and how you got there at the beginning, I guess one of the things that's really interesting is, you interesting is you had a - your YouTube channel was not only publishing very regularly, but they're big time-consuming projects. How are you finding the shift to full-time regular employment with your YouTube channel still going?

[0:39:24] DG: Yes. I've been doing this for a long time and I get to ask this a lot. How do you do all this stuff at the same time? The answer I always tell people is I'm very, very good at time management and scheduling. I'm very schedule-focused. I kind of have set routines every single week. I have set routines every single day and the way that I like to do things. You look at the video here, you can see my desk, it's very, very clean and tidy.

[0:39:49] JN: It's spotless.

[0:39:50] DG: I talk about this a lot, but I don't like clutter in my life. I'm very kind of clutter-free. I do my best work when I have a clean desk. I have no distractions. I spend basically my week just focused on the things that I need to do. So, the answer to your question is I basically have set schedules every week where I focus on work. Obviously, 40 hours a week or 40-plus hours a week, depending on what's going on at work. I'll spend at least a couple of hours a night working on the next YouTube video.

So, Mondays, I'm usually taking a break from YouTube. Tuesdays, I'm starting to write a script or I'm gathering sources, I'm scripting. Wednesday, I'm finalizing the script. Thursday, I'm starting to shoot some B-roll. Friday, I'm doing more B-roll. And then by the time Saturday comes around, I've usually got most of the things ready to go. So, I'm just editing at that point. I'm usually spending some part of Saturday, some part of Sunday editing a video and getting it ready to go on Monday.

That's how I do it. I've been doing that pretty much every single week since 2016. Give or take. I've obviously had some breaks here and there, but that's kind of the way that I approach things. I'm very, very schedule-focused and very set in my ways, I guess, in that regard. Yes, that makes sense. Another thing that I've grown very used to over the last couple of days watching YouTube, as we end to this, is seeing your fans and the comments of every Limited Run thing. People saying, like, "I have Favors Project because MVG is doing it," et cetera, et cetera. Do you think that, well, to the extent you think there was an overlap between people buying Limited Run Games and your audience before? Or is that all folks you've bought into the Limited Run universe?

So, I will say that I try to keep YouTube and work separate as much as I can. There is definitely some overlap, especially when I'm working on something that I think my audience on YouTube would be interested in learning more about. Some of those retrospectives on like Shantae and River City Girls, kind of those earlier videos where I talked about the games that I'd made for Limited Run. But for the most part, I try to keep those two things separate where I can.

But yes, look, obviously, if I'm going to be working at Limited Run and we're working on a game, it's got my name on it, right? And there are people that follow me both for LRG and both for my YouTube channel. So, I want to make sure that people are aware of what I'm doing most of the time. Look, I think that my audience knows who I am and they, a lot of them kind of just follow the work that I do and they'll buy all the games that I've worked on, which is very, very - I mean, that means so much to me that people do that and I really appreciate that. But most of the time, honestly, Joe, I try to keep things separate.

[0:42:31] JN: Yes, that makes total sense.

[0:42:32] DG: A lot of my audience that watches YouTube, there's a different demographic that follows me on YouTube. There's definitely a section that does follow me for the Limited Run stuff, but there's also a section that likes the old Amiga content that we do, right? There's a section that likes the homebrew, the hacking stuff. So, there's different facets to the channel, and I don't want to spend too much time making content about Limited Run Games that I'm working on, because I feel like that's probably taking away from the other people that follow the channel. But occasionally, like I said, I will kind of overlap and crossover from time to time.

[0:43:09] JN: Yes. That absolutely makes sense. So, the last question as we wrap up, either with the Carbon Engine or without with other methods, is there a dream port that you would love to make happen?

[0:43:21] DG: Yes, Chrono Trigger.

[0:43:23] JN: Fantastic.

[0:43:24] DG: I would love to do Chrono Trigger, and I will tell you, I wouldn't - the way that I would approach this, I wouldn't touch the game at all, because I think it's perfect. But you mentioned digging into the archives and getting as much archive material as we can, that would be the exciting part of that project. Digging deep, trying to get all sorts of design documents, prototype, artwork, anything we could find to really make a nice package where we have the game, and maybe we have the game and the various ports to different systems. So, there's a PlayStation 1 version, there's a DS version, there's various other versions. So, maybe a collection of all the games, even though for all intents and purposes, they are pretty much the same.

But it would be nice to have just a complete package of all those games, plus really, really kind of fleshed-out museum section. We also do music players in our games. We have the full soundtracks in our games. Sometimes we'll have remastered soundtracks as well. So really, just make it about the game and the awesome stuff that went into making that game. If there's any interviews, sometimes we go back and interview the original developers as well. For Tomba! we have a section where we went back and interviewed the original Whoopee Camp developers, something along those lines I think would be awesome.

[0:44:40] JN: Perfect. Well, thank you so much for joining me today. It's been wonderful and yes, best of luck continuing to bring us old games back to life.

[0:44:48] DG: Thanks for having me on, Joe. It was a pleasure to talk.

[END]