Ripping the sprites of characters, objects, effects and so on is one thing, but what about backdrops or levels?

Well, the usual approach is just to take lots and lots of screenshots, preferably with layer options to disable backdrops, sprites, etc. This entails just playing through the level, taking a screenshot, moving roughly a screen's worth forward, taking another screenshot... it ain't glamourous.

Needless to say, this can be very, very time-consuming. Both taking so many pictures to begin with, and then needing to stitch them together after the fact! God help you if you're trying to map out an area with little to no landmarks. I still need to explore these resources, but Screenshot Autostitcher looks like it might lighten the workload, and VGMaps is worth a gander for insight from folks who've done more of this than I have.

Croc 2 (Game Boy)

Emulators with built-in map viewers can help somewhat, as they typically show more than what the game's resolution can display. Be aware that they have their own quirks, and might not be a 'clean' representation of the in-game area -- VisualBoyAdvance often has palette issues with monochrome Game Boy games, for instance.

Scrolling the camera will overwrite new tiles as they enter view, meaning you may need to crop and rearrange chunks if you don't align it perfectly within the map viewer. The example above is decidedly not how it looks in-game, but the result of the bottom part of the screen being overwritten by tiles on the mid-point of the area. Tick "auto-update" and walk around in a game to get a feel for how it works.

This is where getting acquainted with RAM tools to tinker with the camera or player's position can shine. Finding out what moves the player or the camera can really speed up the process, no longer bound to where you can just go in-game, and having coordinates you can check is a better way of assuring where you in the level are than relying on landmarks.

It's got the same pros and cons of vanilla screenshot ripping, including a few new ones like fighting to make the camera cooperate -- the level might not load its tiles if you move the camera beyond where the player is standing, for instance! -- but if you can wrangle it under control, it can be a much smoother process than playing the game 'legit'.

Of course, just like tile-ripping, sometimes you wanna go to the source! Games store their level data not unlike tilemaps for sprites -- a hexadecimal blueprint of what tiles go where -- and figuring out how the game stores and employs this data means you can just recreate it yourself!

This requires finding the tileset, and also the map data; finding the latter makes finding the former a lot easier, as if you can edit the level data, then you can just make it print one of every tile and dump them that way.

How do you find map data, though? Well, uh, I usually just delete or deface chunks of the ROM and boot it up to see what I've broken. If I appear in a featureless void, and not because I've blanked a vital part of the game code, then I'm probably on the right track!

After that it's just everybody's favourite pastime: pattern recognition! Is there a pattern to these bytes? What happens if I change these ones?

Although Kid Icarus: Of Myths & Monsters stores its primary level data 1:1 to how it's presented in-game, its dungeons are stored more economically, thanks to their modular nature.

Dungeons are an 8x8 grid of rooms, and there are 30 possible room layouts, with additional presets to determine what objects are in the room, and which exits are available.

This is tangential to the subject at hand, but I'm demonstrating how game data and level maps can be an unpredictable and changeable force, varying even within the same game!

Of course, levels can be pretty big, and this data is likely to be compressed, or even just optimised in some capacity. The likes of Kid Icarus or Super Mario Bros. reuse screens to pad out their levels, so what's in the data might not match what's in-game 1:1. You'll likely hear the term "metatile" in regards to level data; these are prearranged chunks of tiles mapped to a smaller byte, making it a more memory-efficient way of building areas with repeated chunks, rather than writing every single tile while assembling.

Usually the map data and object position data are stored separately, though it all varies from game to game, naturally. Croc 2 on Game Boy uses 'shorthand' code for parts of its map construction, telling itself to repeat a tile X number of times, or code for where exits are meant to warp you. Trying to apply the tileset to this is somewhat legible, but no good as an accurate map rip without lots of editing...!

This is where RAM comes in handy, as it's gotta decode this data to display it properly, natch. Checking for values changing en masse between levels is a good way to narrow it down! Very few games allow you to edit map data on the fly, so if you want to tamper with it to see if you're on to something, you'll want to lock that value before it loads the level.

Basically, what you're trying to get is the level data, the tileset, and knowing which byte correlates to what tile. Once that's figured out, then you can recreate it in your tool of choice:

I can slice the tileset into individual images with StitchStudio, insert the hexadecimal map data into FrontPage, add HTML code to interpret those numbers as images, and it should hopefully read as level data! You might need to fiddle with the page dimensions for it to display properly, or put it in a table or something.

I've yet to attempt this with TilED, but I figure by converting the map data to decimal (to match how the program would read the tileset sheet) and editing it into a map template, it should hopefully cooperate.

my process for extracting maps from Croc 2 (GBC)

Blanking/corrupting bits of ROM to see what changes

↓

Oh, ROM address 40000+ correlates to the hub's level data!

↓

And the bytes at RAM address 1000+ matches that level data!

►

So if I modify RAM addresses...


... I can edit the hub's tiles when it loads to build up a tileset!

►

And if I export those RAM addresses...


... I can rebuild the map by pointing those tile values to the tileset!

I'd like to think there's a better way of doing this, but there's not as many resources on map-making as I'd hope...! VGMaps.com still predominantly promotes the screenshot method, and though there are special level editing tools for certain games, they're typically for stuff that have been documented extensively already. The Mario games are well-covered, but tons of other games aren't so lucky...!

One of the joys of screenshot ripping, tile ripping, or even just using different versions of the same emulator, is that you might describe the same sprite and the same palette will be ever so slightly different. For older consoles like the NES, this is just the nature of their hardware and how they handle colour data; see that section for details.

SNES9x / BizHawk / vSNES
The Simpsons: Bart's Nightmare (SNES)

But for stuff like the Super Nintendo, they've clearly got a 'canonical' palette generated with 2-byte RGB, meaning red, blue and green come in 32 possible shades (or a number divisible by 8 in traditional 255 hex measurement)... and yet between the three examples above, they all give slightly different results. Bart's yellow skin is hex value #FFDE00 in the first, #FFDB00 in the second, and #F8D800 in the last example.

I'd assume the 'true' colour is what's found in your palette viewer, but it's really only a bother when you're ripping sprites using both methods, or using two different sheets and finding the colours don't quite match. Look, in a hobby as esoteric as this, you find new and amazing things to be slightly ticked off by.

VBA and No$GBA arguably popularised the inclusion of colour options to simulate how a game 'really' looks on an actual screen, with faded, washed-out palette referred to as "real colours," and the game-accurate colours in NO$GBA some what patronisingly referred to as "poppy bright". This explains why you might see sprite rips that are strangely desaturated.

I, personally, am not a fan of it. To rip using colours that are as accurate to the original data as possible is ideal, and as far as I'm aware, all those "actual colours" options are just eyeballed from photographs or whatever. I'd sooner give people the option to tweak colours on their own than foist it upon them -- that's what the saturation options are for!

Super Mario Sunshine (GameCube)

Credits will often mention the game and all of its contents are under copyright of such-and-such company... which should mean by extracting and releasing its graphics or music elsewhere, you're infringing upon their rights and breaking the law, surely?

Yeah, probably.

In practise though, this is rarely acted upon. Nobody has gone to jail for ripping sprites, as far as I'm aware; "it's easier to ask for forgiveness than for permission" and all that. Games that outright lift or modify assets tend to be very low on the totem pole of visibility anyway, usually pirate arcade games or dodgy mobile fare.

Games allegedly "copying" one another is something that's very rarely enforced even in the court of law -- see the Capcom U.S.A. Inc. v. Data East Corp. case and Hudson Soft's suit against NEXON's Crazy Arcade (Korean link)...

... and on the rare occasions a modern game has been caught lifting assets, it's more a source of shame among the artists than something the companies seek legal recourse for. Scott Pilgrim vs. The World lifting effects animations straight from Sonic Battle cast a blemish on the artists working on that DLC more than anything else.

Hell, companies like Nintendo have made use of fan-extracted assets, be it fare like The Shyguy Kingdom's specific sprite rips on Nintendo's websites (identified by their exact custom-added outlines and palette choices), or even standardised ROM formats and emulators depicted in the data of some games.

At the time it seemed unlikely that companies kept such resources on hand for graphic design purposes, and nowadays the corporate answer to such things is Google image searching it. It's possible that's changed, but who can say.

a non sequitur to break up the text, or an excuse for Argonaut to sue my ass for playing with their renders like paper dolls? you decide

Fare like 3D models tend to be clamped down upon more often though, likely due to their modular nature -- a sprite is limited to what it's drawn to do, but any model can potentially be applied to an uncouth GMod animation or a pornographic SFM video or whatever.

There's been frequent hullabaloos over games containing content that wasn't meant to be visible under normal circumstances, be it Final Fantasy XV's fully modelled genitalia on most female NPCs; the nude celebrity actor in Beyond: Two Souls; or even old news like Grand Theft Auto's Hot Coffee fiasco. Getting access to a 3D model gives the user a lot more freedom with what they can do with it, which probably ain't great in this PR-conscious age.

The Spriter's Resource forums keeps a list of blacklisted games their developers requested their assets not be uploaded, which is a lot fairer than just DMCA-ing the entire site. One can likely still rip and use those assets for personally use, but sharing them publicly online just doesn't seem cricket.

The Nintendo "Gigaleak" of 2021 was a concern on sprite sites, as I discussed in my I <3 Bowser article; the files were certainly ganked by illicit means, but they're out there now -- does that make it okay to host them? The Spriters Resource and MFGG briefly entertained the notion before back-pedalling, fearing risk of Nintendo coming down on them. It's one of those fussy things where the files are out there and can semi-easily be found, but to organise them into a nice little sheet and share them publicly is considered too much of a risk.

It's typically considered fair game to rip its assets if it was a commercially released game. I feel like it used to be another matter for independent and fan-made fare, but that stigma doesn't seem as prevalent, if the deluge of ROM hack rips on The Spriter's Resource are any indication. Ripping from 30 year old Japanese games is kosher, because they're old as balls and you'd like to assume they got paid for it. But when the developers and artists are accessible on social media with their portfolios available online, suddenly it hits different...?

It's usually a case-by-case basis. ROM hacks, fangames, and indie fare have been ripped exhaustively on tSR, but some haven't been touched either out of courtesy or developer request. For a while it was deemed improper to rip assets from games made with GameMaker or Clickteam software, but with the rise of tools capable of tearing them apart that seems to have changed -- trying to do it before was a bit of a dickens!

The long and short of it seems to be, if you intend to share this stuff with the masses: read the room! If it's purely for personal use and won't be shared, knock yourself out.

It's the nature of people sharing stuff online that they want folks to know who worked on it. A lot of the work on my website is simply about bringing attention to things -- rare manga, obscure Bomberman content, unused Metal Slug materials... stuff that is in no way mine, but still required a bit of work to unearth that might not be visible to folks. It'd be petty of me to scream "your gimmick twitter account would be nothing without my efforts!!", but having people know where it came from and what else can be found is appreciated, y'know?

So by that logic, it makes sense that some folks want you to know they ripped this sprite. The archaeologists didn't make this dinosaur skeleton, nor did the curator make this art, but the unseen work that goes into putting it in front of you on display is still to be appreciated. My old version of this article made a silly analogy using an old I-Mockery article, one that a couple of pals still link to as a handy explanation.

In Ol' #23, this kid paints the Mona Lisa on the ceiling of the bus. He didn't create the original Mona Lisa back in the 1500s, but he mimicked it pretty well and worked day and night on it, so he gets a round of applause. When a rowdy sports team spray soda all over it, he's mighty annoyed.

Game artist makes sprites, sprites are compressed bizarrely yet someone rips them, and rips them good and comprehensively. Person gets internet applause. When a rowdy ne'er-do-well claims them as his own, person gets annoyed.

Except sprites aren't really seen as a level of art anywhere near the Mona Lisa, but I try to make a point.

The context of that aside was in regards to people claiming credit for someone else's sprite rip, a more common occurrence back then for some reason. Having a large, distinctive tag to mark a sheet as your work was more prevalent, an act that evidently rubbed some people the wrong way: to have petty squabbles claiming ownership of a sprite sheet, essentially another artist's work, isn't exactly a good look, but teenagers on the internet have died on lesser hills.

Some sheets, instead of naming who ripped them, say to credit the developer of the game instead, which is fair. It seems like unnecessary text to have on your sprite sheet, but the point stands that it's the artist of these graphics I want to show gratitude to most of all: the act of ripping the sprites is simply to make them accessible.

Credits across all media can be somewhat nebulous -- what particular person was responsible for this specific facet? -- and I wish we knew more about who to thank for what they crafted and the impressions they've made on us. Video game development can be thankless work, and it'd be nice if the graphics designers on Mega Man got to know their art spawned a thousand dodgy sprite comics. Well, maybe not nice, but it's a fact, you can't deny that.