CJ Made A Sega Game in 2025

Welcome to Syntax. I think that that was my first my first one. Yeah. Yeah. Oh, man. That was good. CJ here. And today, I'm talking all about this custom Sega Genesis video game that I made for Century Hack Week. So Hack Week is put on every year by Century. Essentially, everyone at the company gets an entire week to work on whatever they want.

And this year, I decided I wanted to try to create a Sega Genesis game. So with me today is Scott and Wes. What's up, guys?

Yo. Hi. Hey.

Yeah. Node. Don't care about us. You made a freaking Sega game? Yes.

Yes. Holy smokes. Say, why Sega? We all know that Nintendo does what Sega don't. Or Node. Wait. No. Sega does what Nintendo don't. 10 don't. Oh. Uh-oh.

But that's that's my first question for you guys. And first, like, some back some some backstory here for all the the Gen z people watching that don't know what a Sega Genesis is. This is a 16 bit game console that was released in The US in 1989.

So my first question for you two is, were you an SNES guy or a Sega guy? What did you have?

I don't feel like this is a real question. I had the Wes, and then I had the SNES.

I was SNES head all day. I never ever owned a system made by Sega.

I kinda went the Nintendo route up until the GameCube and then moved to PlayStation and then, obviously, Nintendo Switch. Nice. And Wii. I I had a Wii. I I'm a video game, person. Wes is not necessarily, but I I I've played a lot of, video games in my in my life. That's for sure. Men. Still do. So when I was a kid,

we had I just looked it up. Master System.

That's the Sega Master System. Yeah. Yeah. You had the Master System. Interesting. We got it at a garage sale, and it came with 20 games.

And my parents went through them and took away 19 of them because they had fighting fighting in them like guns. So Wow. Yeah. So we had one game for that. And maybe that's why I don't like games because my parents are taking away. And then we had the NES, and there was we didn't have Super Nintendo. Neighbor did. And then I'd, like I pretty much, like, lived on, like like, n '64, though. That was, like, my dig. Yeah. Gaming days. Same.

Wes Yeah. I I guess I had gaming days with all systems. But n '64 for me was high school, which means we're doing, sleepovers. We're playing GoldenEye. We're playing Mario Sanity, pretty much GoldenEye. You Node, it is like yeah. That was for me a lot of '64. Yeah. I I would agree. Like, most of my childhood was n sixty four and then PlayStation one, but the early days

was Sega. And I think probably one of the first memories I have of games is Mortal Kombat. Did you guys ever play Mortal Kombat?

I had Mortal Kombat for Too much fighting.

The Super Nintendo, and it Wes, like Okay. Completely like, my parents wouldn't let me get it. And they they only let me get it for that one because they found out all the blood was removed, and it Wes, like,

yeah, very neutered for sure. So, yeah, I I won't get into it, but there's, like go on YouTube and just look for Sega documentaries. There there's there's one by MKBHD that, like, puts all of this in perspective.

Because back then, that was the deal. It was Sega came out, and to really position themselves, they wanted to be, like, the edgy console. So they had Mortal Kombat. They had fighting games. They were, like, the the game console for for for cool kids, I guess. Degenerates.

Yeah. Exactly. Yeah. Degenerate. Not a little bit. Hold on. CJ, Wes you allowed to watch the Simpsons as a kid? Oh, I was. I wouldn't say allowed to I probably wasn't allowed to play the Sega either. I was very sheltered, but I found ways, and I had friends. So

I could watch the Simpsons. Yeah. Yeah. We could tell, Scott. I am I'm pretty much Bart Simpson embodied. Right, guys? Yeah. You're gonna rock to people. Shorts and all that. Yeah.

Okay. So that that was that was a a fun nostalgia and such, but I'm just gonna go ahead and show you, here is my game running on a Sega Genesis.

Oh, that's so dope. Oh, I guess I'll also say that the modern world of retro gaming is kind of amazing. So I actually use this wireless eight bit do controller, and it works with it works with my Sega. So I can literally be wireless and on my SEGA. So this is the game I made. Right now, it's just a single level, and you are the AI debugger called Sentry. So you're this little pyramid guy, and my idea with the first level is you go through collecting these little balls, and these are traces.

So if you use Sentry, you know that you get traces in in terms of, like, what's happening in your app. Like, was there a request on the front end or the back end? Was there a database request? All of that is traced.

So the idea is you collect these traces as a AI agent, and then there would be another level where you can then use these traces to throw at a bug that you're trying to kill. Unfortunately, I only got this one level working, which is,

I It's good. It's dang impressive. Yeah. I gotta say, for people who are not watching this, if you're listening to this on the radio, CJ is not only just playing on a a normal Sega Genesis. He's playing on a CRT monitor that has, like, refresh scrolling going on on the camera. It is like it it's such an experience.

So if you feel like you'll get more out of this in video, this is on YouTube, youtube.com/adsyntaxfm.

We will be showing things as well. So Definitely.

And, this will be the last time I show you on the CRT because it's really hard to see. The nice thing is you can actually develop inside of an emulator. I'll show you that. But, basically, I was scrambling. This was, like, twenty minutes before, we needed to turn in our Hack Week videos. And so I was like, okay. I have one level. Now I'm just gonna add some text. And so this says, this is where you'd go through all the other levels and then battle a boss, but I ran out of time.

And so that shows up on the screen. That's the game that I built, and I had a fun time doing it. So I'll kind of, like, walk you through what's involved here and also how I even decided that I wanted to do this. Yeah. I'm I have so many questions about

how you know, like like, I remember being a kid and being like, how do websites work? But I Yeah. I don't know that I ever asked, like, how do video games work? And it's so interesting to me that you can just

make one. Node. Yeah. And that's kind of where the idea came from as Wes, because I, same thing, I never I think last week was the first time I was like, I wanna make a custom Sega game. It had never crossed my mind, but, I'm a I'm a developer.

Yeah. Yeah. I've made games in the browser. I've made Unity games.

Why not make a make a Sega game? And as I'll show you, like, the the modern ecosystem for retro games is actually, it's pretty big and and pretty approachable, I think. At least if you have a a basic understanding of programming, you you can you can do this kind of stuff. But I'll also show you the the first demo that I got working Wes the syntax logo scrolling onto the screen. Yeah. That's so cool.

Man.

It's because that Wes running off a cart right Node. Yes. Exactly. It it's running off the cart. So I'll talk about how it's done, but, basically, there's an SD card.

I'll I'll I'll show you on the menu itself. So, if I reset I'm using a cartridge called the Everdrive, and so it basically has a custom ROM on it where Wes you go to select game, this is reading off of the SD card. And so you can see I have two dot bin files.

This syntax dot bin is just a game that loads the syntax logo, and then seer dot bin is the full seer game. But whenever you load it, you choose it, and that actually writes it to the the ROM or the read only memory on the cartridge itself and then reboots into that ROM.

Yeah. Man, and those I don't know if you're gonna get into this, but those bin files are assembly Node.

Or say there there are areas of this where, because it was easy enough, I don't have the full understanding of it. But my my thought is the BIN files actually are binary, but Compiled binary. Yeah. Yes. Compiled assembly code for the Motorola 68,000. So the Motorola 68,000 is the processor that's on the Sega Genesis.

And to write assembly code for it, the Motorola 68,000, there's literally a language that corresponds to that processor that says, like, move memory here, store data here. All of that is specific to the the 68,000, and so your resulting Sega game are instructions for that processor, and then that needs to be compiled into binary so that it can it can run on the processor itself. Okay.

And and those images, like, like, you're not just putting PNGs on that. Right? They have to be converted into, like, byte arrays?

Yeah. Well, we'll get into it. So, yeah, yeah, yeah. That's my question. You showed us earlier, and I was like, I wanna know how that's happened. Go ahead. Sorry. Okay. So first of all, the the way I even thought this was possible is when I so I bought this Sega, and I guess if you've ever seen my backdrop, you know that I have retro computer stuff back there. Right? I've got the Apple computer, and then there's an IBM, first like, it's the three thirty. It was the very first personal PC. So retro stuff. And I had a Sega Genesis back there because, like, you know, trying to relive my childhood or whatever, but I bought this. So this is the, it's a it's a cartridge that has I can't oh, I forgot. This is an autofocus. But this is a cartridge that, has every single Sega game ever made on this one cartridge.

Wow.

Modern retro gaming has this. So you can get a Game Boy cartridge with every single Game Boy game ever made or an n 64 cartridge with every Game Boy game or every, n 64 game ever made. So I already had that. So the gears were already turning of, like, okay. If it's possible to store that much stuff on a cartridge, what are they doing? I I opened this up early on because I was like, oh, is it just an SD card that I can plug in? But they have a a soldered memory chip on the the board itself. It's like a four gig memory chip that has all the ROMs on it. But you can get cartridges like this for retro consoles, and that got me thinking, okay, if they can do that, then can I make my own game? And Yeah. A lot of different ways to go about it, but I came across Wes g d k. So this is the Sega development kit created by Stefan Node Longueville, and he's a wizard. So he created GENS, which is a emulator for the Sega Genesis Mega Drive, Sega CD, and the Sega 32 x. And then he also created the Sega Genesis dev kit. And, essentially, this is a C code dev kit that allows you to write C code that, at the end of the day, will be compiled into the Motorola 68,000 assembly, which then gets turned into a binary. So the SGDK is what allows me to write higher level code to to make the games. I'll say, a little bit of nomenclature.

I learned this as well. The name Genesis is what it was what the console was called in The US, but in Europe and in Asia, it was called the Mega Drive.

And I I learned that last week because a lot of these resources for creating assets and developing, reference the word Mega Drive. They don't necessarily reference Genesis.

So anything you come across that's Mega Drive or Genesis, is the same thing, it's just that's how it was released, not in The US. And I came across this Git repo called Awesome Mega Drive that has everything. So there are people that have created tutorials for using the SGDK.

There's, like, the original Sega Genesis manual. If you really wanna get low level and, like, write assembly, like, there there's just so many resources for this. There's also, like, a a a YouTube video of a guy that wanted to develop games for the Sega the same way that they used to do it back in the day. So he found a Sega Genesis dev console.

He has this whole chipboard that he, like, plugs in, and he's able to, like, write it in real time. I didn't have to do any of that. Everything I was doing is just running on my computer in an emulator, and then eventually, I put it onto an SD card.

Okay. I was gonna ask that because, like, when I've done custom stuff for, like, a ESP 32 microcontroller, there's no emulator for that. So you have to, like, compile the whole thing, load it onto the thing, and then and then boot it up. But, like, what what what does the the feedback loop look like when you're building a a game? You can run it on an emulator?

Yes. You can. So, there are a lot of different emulators out there, and I would say probably the one hurdle I had all of last week is everybody doing this is doing it for Windows. Like, there's barely any resources for doing it on a Mac. Yeah. And then, like, a few for, like, doing it on Tolinski. And a lot of times, the Linux stuff can technically run on a Mac if you, like, recompile it. But that was my biggest issue. And so I actually am running an emulator using Wine.

So Wine, was originally developed for Linux.

It's the Windows something layer. But basically, you can run Windows applications on Linux, and you can use brew to install Wine on a Mac.

I guess that's this one.

So this is running an emulator called Gens. This is the one that Stefan Node. But the nice thing about this one is called k mod, and this actually gives you debug messages. And that's the main thing JS, like, a lot of the other emulators, you just load the RAM in, your game crashes, what happens? This literally has the debug messages window. And so when you load a RAM in, you can actually see any messages that get printed out. They also have a debug window for looking at, like, what are the sprites that get loaded in. Yeah. This emulator is one of the best ones for, like, making your own custom games.

I watch a guy on YouTube, who does, like, changing, RAM values in NES games via an emulator as they're running. And it's like he's showing how things like Game Genie worked or stuff like that. And it's so fascinating inside these emulators to see, like, what exactly is going on.

Yeah. And so this is me running that same ROM right here in the emulator.

And then, one of the nice things about the s g d k is they have just a bunch of samples.

So in the source code folder, there's a folder called sample, and they have all kinds of stuff. So like basics, advanced, games. And so if you go into basics, there is a hello world example that you can just load into the emulator.

Just prints hello world to the screen. And then we can actually look at the the source code for this. Yes. Please do. Yeah. So we have a a main dot c file.

There's an int main.

It accepts a Boolean that's hard reset, and then it uses VDP draw text. So VDP draw text is provided by the SGDK.

You can pass in, what text do you wanna draw, where do you wanna draw it on the screen. So this says, draw text, hello world at x 12 y 12. From there, there's another built in method in SGDK called Sys do v blank process, and this just runs in a loop so that it keeps the draw tech the text that was drawn on the screen itself. Oh, that's a canvas,

except you a very small canvas. Right? Like, what's the resolution?

You're three three twenty by, two forty. Holy smokes. Yeah. So let me pull up the because I have a a global's file where I store all of that. Three twenty by two twenty four is the screen width and screen height.

So you're working with a a a very small area.

Honestly, that's one of the nice things about a fixed area is you don't have to worry about flex Bos or, like, different device sizes. So, like, when I write the text hello world to, x 12 y 12, it's gonna be in the same spot on everyone whoever loads this game because it's always loaded within that same Right. Yeah. You're dealing with a hard pixel resolution. Yeah. Yeah. Is that is that why you like to position things fixed in our CSS battle? Yeah.

He's stuck on Netscape and Navigator.

Yeah. Exactly.

I wish. That would that's, yeah. That'd be nice. Yeah. So SGDK makes it this simple to write your your programs. And then to compile them, you use a custom makefile. So if you've ever worked in C, typically, there's a file called make or make file, and that describes how to compile this program. Yeah. So for example, if we want to compile this hello world example, when you set up the SDK on your computer, it's gonna put a make file in a custom Scott. And so you can say make dash f and then specify at make file. So once I got the whole SDK set up on my home drive, there's a folder called build, and there's this make file dot gin. So this specifically will allow me to compile it on my machine. It knows where all the the headers are. It knows where the s g d k, source code is, and then I can use that make command. So clean will delete the out directory, and then debug will compile it in debug mode. And so I run this command, I have now compiled it into a ROM.

And from there, I can go and reload it in the emulator.

So let's actually just change the text to say hello syntax.

So change the text, recompile, and then inside of the emulator, reopen the ROM. And this was my life last week JS just navigating all these directories,

because they're Oh, yeah. Drive you nuts when it's so slow to go through it? That always drives me nuts when, like, an app doesn't use the built in, like, macOS finder Yeah. And you have to, like, go through some tree structure.

And that's one of the issues of running this emulator inside of Wine is, like, it's emulating the file windows to be able to, like Right. To look look at Mac Bos directory structure and stuff. But, I found it, and now it's now the program says hello syntax. Woo.

Yeah.

So that's that's that's kind of the flow. Basically, write your code, compile, load it in the ROM. I will say there is a Vercel Node extension that I didn't end up using that tries to make this a little bit better. But all like I said, all of this is designed for Windows.

And so I think there is a flow, at least within this extension here, where you can point it to the emulator.

And for certain emulators, it can, like, reload the ROM without you having to, like, go through file menus.

So if you're on Windows, you're probably gonna have an easier time. I didn't work on it long enough to figure that out. It might be possible, but right now, it's like a three step process. Compile, choose the ROM, run. Dang.

That's amazing.

So that's the basics. Now let's talk about, images and assets because that's something that really really makes a game, and the SGDK makes this so easy. So built into the SGDK is a subprogram called ResComp or,

resource composer. It's always funny how something like, resource composer can get a cool ass name like rescomp.

Yeah. Also, these these docs are where I spent a lot of my time last week because they have all of the descriptions of, like, the functions you can call and everything else. But rescomp is just a separate program that gets run whenever you build the program. So part of this generated makefile, inside of there, it has instructions that say, hey. Let's look at the Wes file in this directory for any resources like images or maps or sounds. We're then gonna run those through the Wes Scott tool. And you can see that res comp supports bitmaps, tile sets, images, sprites, and then various types of audio, like WAV, which is, like sampled audio, but they also support XGM, which is kind of like midi, and that it's music that describes the notes and the instruments, and then that gets played through, the actual synthesizer on the Sega itself if you were to create your own custom XGM files. If we wanna load an image, we could use a bitmap. And inside of the res file, you would say bitmap, the name of the file you wanna load in, and then the path to that image file. So let me show you my syntax example.

So I'll show you the the basics because the syntax one gets more convoluted because the image was too big to load into a single one, so I had to, like, split it up.

But if you look at, like, this image example here, in the res folder, they have, this file, a dot res file. So in your SEGA projects, you'll specify all of your resources. You say the type. In this case, they're using the image type. So if we look in res Scott, there also is an image type here. This next value is the name of the variable as it'll be inside of your c program, and then this is the path to that file.

And then there's some other options like compression and and how to load it in. So in this example, they're loading, this SGDK logo into a file called logo AP lib and logo ucomp. When you run the build, that actually generates a header file. So let me run the build for this project.

So we run the build that looked at this res file and then generated this c header file.

And so this is what actually gives us those variables that we can use in our program. So this gives us the the logo AP lib variable and the logo ucomp variable, which are of of image type, which comes from the SGDK.

So with that, then you can write code that actually draws it to the screen. So in our main dot c, in this case, it's using load tile set. So the way that it's loading in this slightly larger image is by turning it into tiles. And then under the hood, Wes d k is able to get all of that tile data and write the tiles to the correct location accordingly.

So the Sega itself works on eight by eight pixel tiles.

Mhmm. So, any image you have, if it's eight by eight pixels, you there is assembly code that says, like, load that eight by eight pixel data into a specific tile on the screen. And so SGDK Bos basically abstracted all of that away. It's basically like, okay, take this PNG, turn it into multiple tiles.

That's all gonna be available, in the compiled program. Mhmm. And then in our c code, we now have access to the tile set, which points to an array that has all of those tiles inside of it, and then we can we can load it onto the screen. That's dope that it abstracts that because that seems like a pain in the ass. Yeah. So this loads it into memory, and then you need to actually draw it. You do you need to do, set tile map e x, and this describes where you should draw it. So this is the other tricky part of writing a program is, like, you're constantly loading things either into, like, video memory or regular memory, and then you're writing code that can access that memory to then draw it onto the screen.

So that's what this line of code is doing. It's saying, draw the tile map for that one image asset onto the BGA plane using a specific color palette. We haven't talked about color constraints yet. And then at this specific location, and then where do you wanna offload it to, in this case, the CSS. So these two lines of code draw those images onto the screen.

How many tiles are there? So it would be three twenty divided by eight.

Okay.

So there are 40 tiles across, and then two twenty four divided by eight would be 28 tiles

up and down. Yep. Man. This is so dope. Yeah. What a, like, a resource constrained environment. Like, I I did a bunch of, like, Arduino programming in the past, and it's it's similar to this Wes you write c and you I had to convert some of my, like, JavaScript files over to just, like, byte arrays. But, like, that's that's all modern stuff. That's crazy. This stuff is, what, 20 how old is this? 25 years old, probably? The

Sega itself was released in '89, so it's 34 years old or 36 years old.

Wow.

Okay. So that's how to draw images. I'll point you to some of the resources I found that were, like, super helpful to kind of break all of this down. This one's from Mega Scott Studios. I believe Mega Cat Studios actually released a modern Sega Genesis game. Yeah. So they had a Kickstarter, I I think. I don't wanna get this too confused. But, basically Sure. They they released a Sega game in the modern pnpm, and you could you could buy it online and, like, play it on your old Sega.

So with that, they have a lot of resources on, like, how to make your own games. And so this tutorial was great, because it talks about, like, what is VDP. So VDP stands for video display processor. We saw that in the method names, like VDP set text. There's also VRAM, which is video RAM, so how you, like, load stuff into video memory.

And like I mentioned, you have eight by eight pixel images that are all of your tiles. Earlier, I mentioned that you don't have to worry about resolution. That's really only if you're writing for a specific region because in NTSC, that's three twenty by two twenty four. But in PAL, PAL is three twenty by two forty. So, usually, Genesis JS Genesys are locked to a specific region. So you're building games specifically for NTSC or PAL.

Right. And they have different frame rates as well. Right?

I believe so. So yeah. So 60 hertz on NTSC and then 50 hertz on PAL. So you potentially if you're trying to do something according to the clock, it might be accidentally running a little bit slower on PAL versus, NTSC.

Unless you prepare for that. Oh, man. Yeah. But the one thing I wanna show you that was really helpful from this guide is how to work inside of graphics on the Sega. So Sega actually has four different planes that you can draw graphics onto, and that's what gives you the, like, the scrolling and parallax effect that you often see in games. So, like, if if you know, Sonic the Hedgehog, it always has that, like, light scrolling backdrop.

That back area there with, like, the mountains and the water, that's being drawn onto b g a or sorry, b g b. That's your your scroll background. Oh my god. And z index. Yeah. Exactly. So that's your, like got z index for sure. And it it was funny interesting to learn about this because I was thinking, okay. Is this an abstraction that the s g d k has made? But, Node, this this is available to you on the Sega console itself.

So it has that back BGB, and then on top of that is BGA. So here, where they're drawing the ground and the trees, that would probably be on BGA.

And then there's also another layer called the window layer, and that likely is drawing, like, the text and, like, the heads up display.

And then there's the sprite layer, which is your, like, moving parts and pieces. So the the character itself would be drawn onto the sprite layer. And so you wanna be some crazy

technical, hacks.

Look up and I'll I'll I'll try to find a video on this. Look up how NES developers faked parallax on the NES because they didn't have access to these layers, where the SNES did have layers like the the Genesis did. And and yeah. That's a that's a whole world. That's pretty dope. Yeah. So it was cool to learn this because now you now you can play around with that. And so,

the game that I wrote, there's a scrolling grid background. Like, I wanted it to look like you're kind of in the matrix. You're inside of a computer fixing bugs.

So the scroll b layer is just a grid that's moving.

Scroll a is the level itself. So I have a giant level image that I'm just, like, moving the location on, and then I'm using the sprite layer to actually draw the player that kind of, like, moves around. Any questions so far? If not, I'll kind of dive into a lot of the tools I wrote and show you some of the specific code for for my game. No. Let's see. Let's do it. Let's do it. Yeah. Let's do it. Okay. So the first day was literally just me getting the thing to compile. So, like, that was great.

Day two was getting images loaded, and so that's when I did the syntax logo image. I got that working on day two. And then on day three, I was like, okay. I can run custom stuff now.

How do I actually build a game? And that's what led me to some work that was done to create the platform engine Platformer engine by Jared Gascon. So they wrote this for the SGDK about three years ago. If you look in their GitHub repo, they have this folder called platformer engine, and this is basically just the source code for a Sega ROM.

And inside of there is where they have all the all the hard stuff. So working with a camera, physics, having a player, being able to load a level tile set onto the onto the the scroll plane.

So all of the hard work was was done already. I didn't have to figure out how to do any of that because you could do all of this manually. Right? You you know basically, what scroll planes you have access to, and you can put put stuff into them, but it's a lot of work to figure out. Okay. Now we need a camera system and and and different stuff like that. So, this JS, like, probably 80% of my code is

using this engine that has the camera and the player and levels and everything else. Yeah. As somebody who's been building a platformer just for fun on Godot and, like, not using a starter kit, yeah, you gotta worry about so much stuff.

Yeah. I really you really take it for granted. Like, ultimately, what I want is Mario Maker.

Like, something that I can just click couple buttons and have a video game and not do any of the work. But yeah, man. That there's so many little things that you don't think about until you get into it, especially with camera position and physics and

yeah. Definitely.

And so this example is actually the one that is included with the SGDK. So when you download the SGDK, there's a folder called samples, and that's what had, like, this hello world and this image example. But if you go into the game folder, there's one called platformer, and this had all of that basic code for camera and levels and physics and everything. So my thought was, okay, I'm gonna start here as a base, but I just wanna get my own level loaded in. Because I'll show you the game that you get with this platformer, and then you can judge me on whether or not I actually wrote much of my own code to see see how much I rip off. Yeah.

This is the the platformer, example Node.

And let me plug in my controller so I can play. Did CJ just plan this episode so he could play a video game on on podcast? Are are you hold on. Are you getting paid

to play video games? I think I am. Have you have you had that realization yet?

I haven't. I've been so knee deep in just, like, getting the stuff we're gonna be at. You're right. I mean, I'm playing games at work.

Absolutely.

So this this is the example, that you get. My next thought was, okay. I wanna I wanna customize this. I basically we we have a working way to jump on the platforms and everything else, but, like, I wanna get my own tiles loaded in here. I wanna be able to customize this map. That is the the next rabbit hole that I went down. Inside of this repo, the platformer engine JS a folder called level.

And I found out that this is for a tool called LDTK.

And so this is a Vercel designer toolkit file that you can actually load in. I think I uninstalled LDTK. Yeah. Because I I didn't like it, and it was very frustrating to work with. I currently have LDK LDTK installed and also had a very similar experience where it's like, it's cool as hell. And it's, like, I warp it to work so badly because of the promise of it. For me, it was connecting to Godot. I was having a hard time with that. It's cool. It's it's it's modern. I'll say that. Like, the one that a lot of people use is called Tiled, and it works in a very similar way, but it's supported in a lot of other places.

And spoiler, that's what I ended up using instead.

But I started here because I saw that their example was using this LDDK file, and it had, this tiles export file. So this one file here basically describes where all the tiles are. So if I wanna turn this into my own custom game, it's just a matter of loading this into an image editor and changing what each of these tiles Yarn, and then reloading the game and see do do those those assets get applied. And part of LDTK is it takes that tile map, combines it with this LDTK file, and now we have an entire level that was designed.

So I ESLint an entire day just trying to get this working with my own custom tiles, and and I kind of got there.

But the next thing that you'll run into is, okay, well, now I need collisions as well. So the fact that the player, when he goes to these specific platforms, is not falling through them, that means there's some collision data somewhere as well.

And this example did not have that. If you look in the source code, it's literally just a hard Node, in by in array. Why? That's I don't know. That's what I like, that's why my first day was like, okay. Now I'm gonna build a tool that can turn LDTK into collision collision app.

This map dot c file is just a giant, 48 by 48 matrix that describes where all of the collisions are. So everywhere you see a one in here JS where this this player is colliding with a specific platform.

God. What's crazy is I have CJ's video zoomed out right now, and I can if you just look at that array, you can see the collision areas just by glancing at the array because the ones and zeros

Yeah. Are like a nasty one. So, honestly, if if I was a better planner, I would have just gotten this working first. I would have just been like, okay. Let me just put a bunch of ones and zeros to design my own Vercel, and then, like, that get that loaded in. But I I wanted something better. I wanted to be able to just directly modify the tile map and then recompile my game, and everything's good to go. And so that's that's what I started working on next, and that's what led me to to use Tiled. So this is this is my map loaded inside of Tiled. It has multiple layers. So I have a background layer where I can define where all of these tiles go, and then you can on the right hand side here, you can see my tile map. So this is my cyberpunk inside the computer version of that tile map that we saw for the example game. And in here inside of tiled, I can basically just, like, choose some tiles and then draw them onto a specific layer. And LDGK works in a very similar way, not as intuitive to use, and they have a lot of extra features, but that's my background layer. And then I could have another layer, which is my base layer. And so this actually draws where the the platforms are, where the player can go. And then I have another layer called collectibles. So this defines where all of those traces should spawn.

On top of that, I have a collisions layer. So this collisions layer basically says that for any one of those platforms, it should be a ground tile where the player does not fall through it. So I spent a whole day writing an importer that could take this TMX file defined with tiled and turn it into resources for the Wes d k and load in each of these layers in a way where I could just use it directly. Wow.

So and so I guess I can show you, like, literally, we could redefine the layer, compile it, and we're good to go. So, like, let's just add some some more stuff.

Now I just save this file, recompile my game, load it into the emulator, and the the the level is is ready to go. So I've kind of have more of a modern,

workflow in terms of being able to, like, change my level, change my assets, and then load that into the game. Man, I you I think you'd be interested in how Godot does some of this stuff too. Because they have a built in tiling thing, which, my understanding is it's better than the way it used to be.

But you are yeah. You're on individual tile types. You're defining what those collision areas look like on a given tile, and then you don't have to have a separate layer.

I think some people still do it with a separate layer, but I believe you you're defining that collision on the the the tile set itself.

Yeah. And I I think I technically could do that as well. Like, basically, if tile ID is 35 or whatever, treat it as a collision versus trying to load the collision layer separate. But, yeah, I I think you you can go about it both ways. But once once I got that working, it's just a matter of, like, designing your level now because you can see I I reloaded the game in the emulator, and all of those spots now have those tiles appearing.

And so it's really just a matter of go over to tiled, change what you want, recompile your ROM, and now you can you can play around with it. It. That is so cool. How how appreciative are you of JavaScript and CSS

now that you've done this?

Much. But at the same time, I actually I also appreciate how low how low level this stuff is. And, like, with c programming I mean, anybody that knows c that's watching this, I might make you cringe at this ESLint, but, basically, a c program is just everything's in the global state. So, like, every variable you define everywhere is available everywhere even if it's in another file.

So that's a little bit freeing as well because you're just I like global. I I That's true. The guy that likes global. Yeah. Yeah. Like, every every image is in the global, you know, and, like Mhmm. Everything gets overwritten. But, like, I guess, how much c can you write before you fill this thing up? You know? You can't get into too much trouble.

No. I mean and the thing is before I added the background music, my ROM was still only a 128 k, which the Sega roms can support up to four megabytes.

Oh, wow. Oh, so you could you could have gone,

what, like like, 20 times bigger? Yeah. So I like, my example map like, I I I had big plans. You can see that my Yeah. My my canvas was this big. So my idea Wes, like, each each vertical layer could have been a different level that you're inside of with different collectibles, different, enemies that you're fighting against.

That's so dumb. I I got a question about, like, debugging. Like, how Yeah. The entire state of of where you're at, that's just stored in in memory. And I know that, like, a lot of these emulators will allow you to just save a game anywhere. And is is it just taking, like, an entire snapshot of memory and putting it in? And is that how you Deno warp to debug,

like, a certain level? Yes. But also, we we have logging. We basically have console logs, which I'll show you. But you're right about that, Wes. It is just RAM. And here's something really cool. Any video game that saved your progress on the Nintendo or any system that didn't have a memory card system, if the system doesn't have a memory card system, the way that video game saved your progress when you shut them off was by having a literal battery inside of the cartridge. Yep. So that the game wouldn't shut off. Isn't that crazy? Before that, they did passcodes, which did which the passcodes then reset the RAM values. And, like, that's how, like, motherboards work still. You know? Like, there's a coin cell that keeps time.

Yeah. First of all, I'll show you what I ran into also and why this game isn't finished. If we open up the debug logs on here, I am running into DMA temporary buffer fool errors, because I'm trying to load too many tiles onto the screen. I know there's a there's, like, a smart way to do it, but, basically, I have overloaded the video RAM with too many tiles because I have background tiles, foreground tiles, sprites.

But this is the debug message log area. So you can see I actually have some debug logs when the game loads up.

So the size of the map that has the collectibles and then those circles, I'm calling them traces. This is what your character is collecting. You can see the specific positions that they that it got registered from. These are these are my debug logs when I was figuring out how to load in that layer with the collisions and then positioning them in the right spot. And then inside of Wes d k, there's a method called k log, and this lets you just write things to that console that'll show up here as as debug messages. So, game is loading. I can I can define custom levels? I have this, like, tile editor thing in in the loader. But first, let me show you how I'm actually loading this this level in. So we talked about rescomp earlier. It supports TMX files directly. So the s g d k rescomp has already been written to take in that TMX file. And this is one of the reasons I switched to tiled instead of LDTK JS they already have a loader that can look at that file and then load it in to be used.

The one issue that I ran into is if you have separate layers like this, they weren't accessible as exact arrays so that I could see, like, the the x y coordinates of the collisions.

Basically, it it would load that data in, but then it would just be, like, in memory.

I I I need, like, an in by in matrix so I can Sanity does this specific tile have a collision inside of it? So part of ResComp is you can create custom loaders. And in their docs, they mention extensions.

So you can write an extension in Java that defines a new resource type and then loads it in, yourself. So part of the code that I have written here, I have my own custom extension that defined the collision tile map resource type, and then also the map auto pallet processor, which I'll talk about in a second.

So when you when you look at my my resource file to load that world map in, this is my custom type here, the map auto palette and the collision tile map. And then this is just custom Java code, and I use the existing SGDK Java code as a as an example that can load this file in and then create the correct c header files and c files that can then be used by my program automatically. So that made it so that I didn't have to have a big in by in matrix manually updating in my code. I just set up the resource as a collision tile map, and then that becomes available as a a variable called the collectibles map, or the the collision map.

And then in my header file, these are all of the variables that get created to then be able to use them. So this collision map is a tile map, and that then is used in my codes to determine when a player is moving, are they colliding with the ground? It basically takes in that collision map and then makes it available so that in my other pieces of code on any given tile, I can determine is this a ground tile or or a blank tile. Yeah. So this is this is all just so

dang different in a good way. I mean, I I've done game programming a bit, but, like, this is so like, I love taking little detours from our our, our web dev world to see stuff like this.

Yeah.

Yeah. Unreal.

Being able to, like, dip into all of this and to think that that's how these games were were were made.

And it was even harder back then too. Yeah. It's been harder. Yeah. It's always Yeah. This is hard, but it was even harder. Like, did they they didn't have emulators?

I guess they they probably would have been, like, a kids. Like a development

units. Right? But they're running on the computer. Yeah. If you're interested in this, folks, Retro Game Mechanics Explained, there's a few YouTube channels that do some really cool stuff where they talk in-depth about, like, let's debug this, like, one of them. Here's here's, like, a Contra game from the NES. It was like, a Contra three or or it may have been whatever. And it has this lag. Let's figure out why it has this lag. And they go through the the ROM, and they go through the code, and they find out, oh, they're painting this in this way, and that's why it's creating this ROM. They could have done this to fix it. It's, like, the coolest stuff in the entire world because of just how intense the

solutions have to be in the memory management and the tile drawing. It's so creative. Yeah. And this, I think, is the YouTube video that yeah. So the the Sega Mega CD development unit. So this is one of the, development kits where, this is what developers would have on their desk when they were writing custom, games for the Genesis, which also supported Mega CD.

But as you can see, it has the the cartridge slot on the top too.

Yeah. That's crazy.

Yeah. So, yeah, I think I've covered everything. The main thing is that it was also super hard and probably what took me the most time is is just graphics.

So Yeah. I talked about, like, the different scroll panes and everything else, but the other thing to think to know about is your VDP Color RAM.

So the Assega Genesis supports 256 colors in total. So two two hundred and fifty six unique colors, you can put any one of those colors on the screen.

But for any given tile, you can only use up to 16 colors in that one tile, and you can only have up to four palettes loaded at a time. So on one single screen, you can only have up to 64 different colors being drawn on the screen. What that kind of boils down to is to make it super simple, I just made it so that all of my assets use the same 16 colors, because beyond that, you'd have to be swapping palettes and coming up with a well, actually, I have I have two palettes. I have a palette for the tile set. I have a palette for the player, and then three palettes, and then a palettes a a palette for the traces themselves. And so that's basically three different color swatches, you could say, that have access to to actually draw things on the screen. And so because of that, the in the early days of trying to get my custom graphics on here, it just looked horrible. It was like these weird inverted colors and, like, I couldn't figure out exactly how to get it into the right format.

So I built a Wes app to help me with that.

So this basically allows you to, load a file in and then generate a palette. So you can see here, here is my my my tile set. This is the original tile set as it was inside of Figma, and then my tool extracts out the 16 or sorry, the 15 best colors plus transparency. So left hand side is the original image, and, basically, what I did inside of Figma is I overlaid my own things on top of that original player, tile set that was in the example game.

So I'm putting my pixels on my my tiles on top of that to make sure they're, like, aligned where they should be.

And then I have various images that I use Midjourney to generate, and I'm kind of, like, placing them there. So work inside of Figma. But then once I have it inside of Figma, load it into my tool, generate the color palette, and then I can go in and decide, okay. That color there, I actually want that to be, like, a pink color. On the right hand side is an image that is only using 16 colors in total. And how did you build this? Purely vibe coded. I did not look at the code since I so this was made using a cloud code. I was like I I get I had a whole prompt of, like, I've got images. They need to be 16 colors. We need to extract the most commonly used colors. Mhmm. And then I just I just vibed my way into a UI that, at this point, would let me export it, and then that file is ready to go for res Scott. Res comp will read this, file that only has 16 colors in. Exactly. It won't even error out because it's just 16 colors, and then I can use it inside of my game.

Man.

See? Yeah. Yeah. This is what vibe coding is good for. Yeah. Dang. Building tools that you need quick and dirty. Because you you could've spent all week just building this tool alone. Right. Exactly. Yeah. Exactly. Or the Wes Scott extension.

Or I haven't showed you this, but I I basically have these bash scripts that also use ImageMagick to convert images. So, like like, technically, the exported image here is fine, but it's not the exact format. Yeah. I can run it through ImageMagick and make sure that the the color bit depth is only four, and it only uses 16 colors. And but, yeah, all these all these little one off scripts, AI was perfect for that. Deno.

Okay. DJ. Yeah. I think that's that's all I got. I I think what I'll what I'll leave you with is I is I got a game working. I'm proud of that, but there's, like, so much more I wanted to do.

What I learned is that Sega controllers are actually just nine pin serial communication, and people have actually created projects where you can send and receive data over the controller port.

And so I bought this custom cable. Like, this is actually a breakout board, that I was gonna, like, hook up to an Arduino Node then, like, Sanity even can't even get it open. But it breaks out wires from here to an Arduino, and then I could, like, read and write data into the Sega. I wanted to do that.

Also, you could create a fully custom ROM. So there are these flash carts that have empty memory.

And instead of, like, inserting an SD card, you could buy one of these by a flashing tool and then just put the ROM directly onto the cart itself, and then it'll just it'll boot directly into the game. So, yeah, I wanna do that in the future, and then get it connected to the Internet. I initially, I thought it would have been so cool to, like, see your Sentry issues listed out on a Sega Genesis,

but I didn't get there. Wait. How would you connect to the Internet?

Well, either the Arduino or on the other side, you have, like, a Raspberry Pi. It's connected to the Internet, and then it could communicate over serial to, like, push data to the ROM. Oh, it would send the data over serial.

Yeah. The thing is, there is Mega Drive Wi Fi. People have created a custom cart. So, basically, this is the thing that gets inserted into the Sega. They've created a custom one that has, like, a Bluetooth and Wi Fi module on it. Wow. Yeah. People have done some crazy stuff with this thing. That's cool. Man, I I saw

I forget what it Wes, but some some conference, people had, like, the the crappiest keyboards ever, or or, like, the crappiest way to transmit data.

And it was just like like like, one output and one input, and you had to build something in between. So there was, like, some, like, some physical stuff. Some some was, like, sending sound and and receiving it. And, like like, I guess you could send any data over, over just, like, ones and zeros. Right? So that would be you could just you could send it over ups and downs as well. Oh.

Yeah.

Yeah. Ups and downs. Crazy.

Yeah. Last thing, I didn't tell you about the music. Because of rescomp, I could just load WAV files in. So I used Suno, which is like a music generator, to come up with some, eight bit sounding music, turn that into a WAV file, and then ResComp was able to load it into the game. I do wanna play it for you because this was the other cool thing is, like, just like modern, cool electronic music actually playing on the Sega. Because back then, we didn't we didn't know about dubstep or, like, drops or anything like that. Oh, yeah. Modern cool music. We didn't know about dubstep. No. No. No. So, being able to hear that kind of music on the Sega itself is also a trip.

So the jump is like a hover sound.

There's like a scan sound when you collect the traces.

Yeah. So so, yeah, that's the game. I had a ton of fun. There's so much more I wanna do. Yeah. Oh, and I guess I didn't show this, but I made a physical box. I kinda showed that at the beginning. But, like, at the last second, I was like, there's gotta be some way I can, like, show what I built and, like, having a physical box where I, like, printed some art on was part of it as well. Hell yeah, dude.

Wow. What a heck week, guys. We have a video game that uses hardware and software. We have a a hardware and software LED crappy monitor, LED panel that is so Node, and then, a coding game. And then we're gonna actually bring on Randy to talk about his project in another video here because well, Randy did something very interesting. He built a whole thing vibe. He vibed it. He's not a developer, and he built a whole usable thing. So it's gonna give us a chance to talk to somebody who's coming at this from a complete Node developer perspective. So keep your eyes peeled for that one. It's going to be a lot of fun. Any closing thoughts or anything, you wanna hit us with, CJ?

No. I think what one thing I will do is get this game working on the web because there are emulators that can run-in the browser. That'd be cool. Yeah. I didn't think to do that. I should literally have a site where you can play my my dumb one level game. So, yeah, I'll do that. Look out look out for that. I love it. Hell yeah. Alright. Thank you so much, CJ. That was super cool. Kinda tempted now to to go try it myself. I appreciate that, and, we'll catch you later.