Curation Tutorial

The following page is a tutorial on how Flashpoint works, and how to curate games.

How Flashpoint Works

Before you curate, it's worth understanding how Flashpoint works, as understanding what exactly Flashpoint does to play games will help you grasp curating later on.

See, Flashpoint is more than just a file and a program to play it. Flashpoint's underlying tech is actually a combination of two main programs working in together - a web server and a launcher. A web server is what the internet works on; computers around the world run web servers to host you when you visit a website. The entire internet runs on these web servers. When you open a page to, for example, YouTube, your computer is talking to a web server. Flashpoint runs a web server on your local computer.

These techs work together in order to, in as basic terms as possible, pretend to be the internet. See, we need to do a lot of things to preserve Flash (and other kinds of) games:

• Pass sitelocks. Some games will only run properly if they can detect they're on the proper internet.
• Load resources. Some games will try to load resources directly from the internet, and fail if they can't.
• Emulate servers. Some games will try to talk to servers (an example is Happy Wheels loading custom levels). This is impossible to do without a proper server.

You can hack SWFs on a case by case basis (though you should also keep the original file), but Flashpoint is a preservation project - we're trying to keep the games in as an intact state as possible, for historical and practical reasons. For this, we use this technique of pretending to be the internet. We use each program's proxy settings to tell our software to talk to this 'fake internet'. That way we can keep copies of websites on the local hard drive, and point programs at this 'fake internet' to trick it into believing it's talking to the real internet. Using our fake internet to run web games from is the best approach, thanks to being able to naturally avoid all three of the problems above. With that said, I'm going to outline below, step by step, how it works.

• Flashpoint starts, including our two main apps:
  • The launcher, for the player to interact with.
  • The server, which is hosting our fake internet.
• The player picks a game to launch.
  • The launcher starts up the program to play the Flash game (in this case, we'll say it's the Adobe Flash Player Projector - a single window to run an SWF file, hereafter referred to as the projector) and it passes along a web address; this is where we're hosting the game on our fake internet.
  • When the projector opens, it loads our custom Flashpoint Proxy library. This library tells the projector to talk to the 'fake internet' on the server.
  • The projector agrees, and uses the fake internet. It says hello to our fake internet and asks for the web address.
  • The fake internet (really the web server) looks inside its local files for the web address in question. This is in Flashpoint's "Legacy/htdocs" directory, with subfolders for web addresses and files further along in more folders.
    • If we're talking about Flashpoint Ultimate, the file will already be there, and it'll pass the file along to the projector.
    • If we're talking about Flashpoint Infinity, our fake internet will check if the file is there, and pass it along if it already is, or download it from our Infinity server if it isn't, then pass it along.
  • The projector loads the file, and you can play it. Hooray!
    • In the case of a game that has a sitelock, as long as it is on the right address, the fake internet looks no different to it than the real internet. Therefore, if you put it in the exact right spot that it thinks it needs to be, it'll bypass the sitelock without a fuss. It's the same deal with extra resources; as long as the files are on the fake internet where the game expects them to be on the internet, it'll just work.

To summarize, we're hosting a fake internet inside our Flashpoint file directory on our own computer, and using a combination of all the software at hand, the software used to play games by talking to the internet is redirected to our fake internet hosted from our hard drive, and loads games from there.

Setting Up Our Software

To actually rip games from the internet, we are gonna need some software. This guide will be purely curating Flash games; if you want to curate something a little more complicated, it'll need more than this guide. This is just meant to show you how Flashpoint works at a base level; you can build on this knowledge later if you need to on other tutorials.

With that said, you will need some extra software:

• Flashpoint Core. This is a version of Flashpoint that only has a handful of games; it's mainly meant for adding, testing and just generally playing around with the platform. You can usually find a link to it at the bottom of the Downloads page. You can use another Flashpoint distribution, like Infinity, but it can be annoyingly easy to break Flashpoint in the middle of this; at least Core can be used as a disposable platform that you can just re-extract if something goes wrong.
• If you're doing simple, one file SWF games, you can make do with a modern browser like Chrome or Firefox. These browsers have a built in network monitor that we can use to find and grab individual SWFs, and sometimes multi-asset titles with low amounts of resources.

There are more tools that you can use, but since we're not dealing with multi-asset games yet, we're just gonna work with these two for now. Download Flashpoint Core, extract it to your hard drive, run it via the usual shortcut, and make sure that the included Flash game plays properly before you continue.

Grabbing Our First Game From The Internet

We're going to start really simple; we're going to curate a game that's a single SWF file, has no sitelock, and is just easy to get along with.

Here's the link. Yep, it's Interactive Buddy. We already have it (and you should always check the Game Master List before you curate something) but it works well as a tutorial. You might need to enable Flash to get it to play (just clicking on the middle of the screen and clicking 'Enable Flash' in the top left should be enough. It's worth noting that you can't do this tutorial if you have the Newgrounds Player enabled.)

Now, if you're using Chrome or Firefox, press F12, and don't panic at the overwhelming panel that just showed up on one side of the screen. We only need to focus on a couple of things going on with this. You should see a tab called "Network"; click it. This panel lets us see what is loading on the page in real time as it loads. It should be on 'All' by default, which *might* work, but thankfully, the browser makes this easy for us by letting us filter files that are 'abnormal' by clicking the "Other" tab in the row next to the "Filter" box. Once you have the Network tab open and Other highlighted, click the Refresh button on your browser.

You'll probably see a fair few weird entries there, but if you hover your mouse over each entry on the list, you'll get a full URL of each file as a small tooltip. There's one in particular you're looking for: here's a clue, the URL will have "swf" somewhere close to the end. You can also look at the "Size" column if this is your first time loading the file; it'll probably be a lot bigger than most other things on the page. Once you have this file, right click on it, and click "Open in New Tab". You should be prompted to save the SWF somewhere, but if not, just press Ctrl-S and save the file somewhere you'll remember.

Moving Our Game Into Flashpoint

Congrats, you just downloaded your first SWF. There's more to it than this though, don't celebrate yet. Go to where you saved that file, and copy it (right-click in Windows, hopefully you know this by now). Navigate to where you extracted Flashpoint Core, and go into the Server folder, then the htdocs folder.

Time for a bit of an explanation. This 'htdocs' folder is the root of our fake internet, the very peak of it, and the folders that go down are fake 'websites' that are hosted in Flashpoint when it launches, and for our software to talk to. We need to keep an eye where we paste any files into this folder, so that we can efficiently put our game into Flashpoint later on. With that said, you should already have an 'uploads.ungrounded.net' folder in the htdocs folder. For now, let's go into that folder, then paste the SWF we just downloaded straight in there.

Now we can go back up two directories and launch Flashpoint Core. In Flashpoint Core, you should see, in the bottom left, a "New Game" button that you can click, and get a list of things on the right. There are four things we need to pay attention to at this very moment:

• The title. We need to be able to tell it apart. Name it "Interactive Buddy" or "Test Game" or anything you like, it doesn't matter at this point.
• The Platform. This determines what XML this goes into (our database is split into different platforms - Flash, Unity, etc.). For the purpose of using Core for testing purposes, this isn't massively important, but you need to select one for this to work, so just select Flash.
• The Application Path. This determines what piece of software is used to start up the file we specify. In this case we're using a single, simple SWF, so we want to pick out the Flash Player Projector; in the current version of Core, this is listed as "FPSoftware\Flash\flashplayer_32_sa.exe", so pick that.
• The Launch Command.

There's the big one. We need to talk about URLs now. On the normal internet, a URL, for example, will look like this:

https://uploads.ungrounded.net/218000/218014_DAbuddy_latest.swf?123

This URL is split into a few sections.

• "https://" < this is what determines what protocol is used. For those of you who don't want an internet lesson, this will pretty much always be a variation of http:// or https://
• "uploads.ungrounded.net" < this is a domain; basically a folder that determines where something is on the internet.
• "/218000/218014_DAbuddy_latest.swf?123" < this is the rest of the domain; folders leading down to the file, which will load.

We need to create a URL inside our fake internet for our Flashpoint Core to load in the same way, so let's put one together, piece by piece.

The first part is the "https://", however, I need to say this here. Due to a lack of technology capable of doing the job, using a "https://" in the Launch Command will always, always load files from the real internet instead of from the fake one. This cannot be avoided, this is an easy mistake to make, and it sucks, but it must be noted and checked for. We can end up accidentally loading a game from the internet, seeing it 'working' in Flashpoint, and then have a surprised Pikachu face six months later when the site goes down and suddenly the game doesn't work. To summarize, always use http:// at the beginning of a launch command, NO EXCEPTIONS.

http://

The second part is our domain. On the real internet, this is almost impossible to visualize; top level domains are talked to via DNS, which redirects you to the correct server. Thanks to the way Flashpoint works, though? It's a lot more simple than that. Our domains are all contained in the first folder of htdocs; all of those folders you saw earlier are domains. In our case, we moved our SWF into the 'uploads.ungrounded.net' folder; so that'll be the next part of our URL.

http://uploads.ungrounded.net

The third part and beyond are the subfolders inside the domain, and the file on the end. Every time you go into a folder, whether it be the domain or any subfolders in said domain, you should add a slash onto the end, like so:

http://uploads.ungrounded.net/

This tells our fake internet to look inside the uploads.ungrounded.net folder in the htdocs folder for where it needs to go next. If we wanted to go into another folder, we would need to add the folder name on the end of the URL, followed by another slash. For example, if I wanted to go into the "59000" folder? It would look something like this:

http://uploads.ungrounded.net/59000/

In our case, at this moment? We don't want to do that; our SWF that we downloaded and copied in the previous steps is just in uploads.ungrounded.net. When we're in the folder we need to be in to get to our SWF, all that's left is to put the file name on the end of the launch command. So our launch command, assuming you didn't rename the SWF you downloaded before (good behaviour, you'll see why in a bit), your launch command should look like the line below.

http://uploads.ungrounded.net/218014_DAbuddy_latest.swf

Once you have your full launch command, paste it into the Launch Command box. Once you have a title, platform, application path and launch command filled in, click the tick in the top right of the edit dialog, and the box containing the title should appear in the games list, in which case you should be able to just double click said box to launch the game. If you do so and see Interactive Buddy after a couple of seconds? Congrats, you did it.

Sitelocks

That's your first game working in Flashpoint. Now to do something that's a little more...how do we put it, locked. See, Flash games were well known back in the day for being 'sitelocked'; a process in which the game would check what domain the game was being hosted on, on startup. If it wasn't on a domain that it would like, it would fail, and usually prevent you from playing the game. While this did help things like revenue shares, at least to some point, sitelocks would eventually come back to bite Flash preservation in the butt in more than one way. A lot of Flash games would, if downloaded to the hard drive, still run off the same sitelock, and since Flash can also detect whether it's being run via local files, the sitelocks would trigger and you couldn't play the game.

There is also a second case though, which is much rarer, and 110% more hilarious. See, sometimes website designs can change, and this can result in certain games sitelocks being specific enough that even the little changes they made are enough to set off the sitelock. Allow me to show you an example, which we're going to download and curate. Open this URL in your browser, and try to play the game in question: http://andkon.com/arcade/adventureaction/monsterslayers/

Yup, it actually sitelocks, and not only that, it tells you to go to Andkon Arcade, where you already are, to play the game. I'll let you get over the fit of the giggles this absolute nonsense brings about, and let you grab the SWF the normal way. Once you have it, we're going to put it exactly where it is on the real internet, then load it via Flashpoint, to show you that this isn't a fluke, this is actually the sitelock in action.

So here's the URL of the SWF in question.

http://andkon.com/arcade/adventureaction/monsterslayers/monsterslayers.swf

Let's break it apart into individual folders.

http:// andkon.com / arcade / adventureaction / monsterslayers / monsterslayers.swf

If you've been paying attention you know exactly what to do here, but if you don't, we're gonna make this exact path in Flashpoint Core. To do so, we're gonna go to Server/htdocs again, and we're gonna make an 'andkon.com' folder, then we're gonna go into that and make an 'arcade' folder, then 'adventureaction', then 'monsterslayers', then we're gonna paste that SWF in there. The upside of this approach of placing the URL exactly where it is on the real internet, is that we can copy this URL, and use it as our Launch Command, exactly as is!

NOTE: remember that some URLs can still use https:// at the beginning, so doing a copy-paste of that into the Launch Command will not work right if you forget to make it http instead of https.

So you can either make a new game entry like before, or click on the one we already made, click the Edit button (it's a pencil in the top right on the right sidebar) and change the launch command there, then click the tick. Either way, do that, then try to launch the game, and you'll see the sitelock there, clear as day, just as it was in the browser. Now, as for determining what exactly this kind of sitelock wants...well, that's a tutorial for another time, but since this version of the game is already in Flashpoint, we already know how this sitelock works, and can fix it right away.

See, the way Andkon used to be structured is that it used to run on the domain "arcade.andkon.com" and not just "andkon.com", and the sitelock on this particular game was designed to check that it was running on "(something).andkon.com" and not just "andkon.com" because of that. When Andkon updated at some point in the past, it broke this sitelock code, and the game wouldn't run properly. Thankfully, we have a fake internet we can bend to our will, so this can easily be fixed.

With that said, I'm going to put on the Jeopardy music, and let you see if you can figure this one out. The file is in the domain "andkon.com" at the moment, and we need it to be on "(something).andkon.com" for it to work right. How would we accomplish that, and what two things would we need to change to make it work?

...

If you answered "the domain folder in htdocs" and "the Launch Command of the game" you're correct!

• We need to change the name of the 'andkon.com' folder in order to fool the sitelock. So if we go back up into htdocs and rename this folder, we can make it work. (In this very specific case, we can use anything as a substitute for the (something) in '(something).andkon.com'. For my example here, I'm going to rename the folder to "bumfluff.andkon.com", because seriously, in this one case that works.)
• But once we've done that, our Launch Command becomes invalid. See, it'll still try to load 'andkon.com', and it will probably fail. At least, it will absolutely fail on a fresh hard drive. In order to compensate for this, we also need to go and edit the Launch Command in the game's entry in the launcher to match up with the domain's new folder name.

Once you've done that, and you can launch the game again, you've successfully bypassed a sitelock. Congratulations, again.

I want to end this section off with a note about sitelocks; in most cases, sitelocks are still working as intended on most Flash portals, so grabbing them, loosely throwing them into Flashpoint and playing them just won't work, which is why recreating the exact structure of where the game was on the website, like we did with Monster Slayers up there, is always good practice; not only do you ensure that a loose SWF floating around in the master copy doesn't overwrite any other files, any sitelocks that might come up will be headed off at the pass, because you already put them in the right place on our fake internet to fool the sitelock to begin with. Two birds, one stone. There's also the third benefit of keeping the files like this being historically accurate, which is good for a preservation project. So basically, always have the game in the right place.

Multi-Asset Games

Multi-asset games can be a lot trickier to deal with. When we say multi-asset, we refer to a game that loads more than the initial SWF when you play it. See, Interactive Buddy and Monster Slayers were all self contained in one file, no fuss, no problems, load them and go. But remember that we were dealing with games that were likely to be loaded on dial-up connections, so for some titles, every kilobyte you could save on loading games would work - giving someone on dial-up a 2MB game to download at first to let them play a little, instead of forcing a 20MB download that would leave it unplayable for them, was considered a good thing in some circles.

This also leaves things like Flash games in a really tough spot when you try to back them up. Sometimes these games are programmed well, and will load the resource from the folder the actual file is next to. Sometimes they'll just talk to an absolute, direct web address, leaving it unplayable once that file goes down. It's almost impossible to tell that this might be a thing sometimes. With that said, we're gonna back up a multi-asset game, and hopefully give you a tool or two to help with these games, although it's never a guarantee.

The game we're going to be using is adventure title Gateway II, hosted on the developer's site here: http://cockroach.se/gateway_2/ Before you allow Flash Player through though, make sure you hit F12, Network tab, Other highlighted. Then once you start to play the game, you'll notice that instead of one SWF, it loads a relative ton of them, and also some XML files. In the case of Gateway II, you need *all* of these files to actually finish the game. As an experiment, feel free to download gateway_2.swf, then try and play it, just by itself, in Core, using the methods we've gone over. You'll get to the language select, then you'll stop dead once you pick one.

Now, the hard way is to download all of these files manually, make sure they're in the right spots, and that will basically do it. If you scroll over the list of URLs, you'll notice that they're all in different directories in relation to eachother, so it'll actually be a lot of manual groundwork to get this done right. You can do this, and I recommend you do it at least once, to get used to the idea of making sure everything lines up nice and neatly; when one file ends up out of place or forgotten, you'll either not be able to play the game, or you'll submit it, only to end up having someone complain later.

Thankfully, we do have a tool to help expedite this process; it's called cURLsDownloader, and we can make it work for us pretty easily. So when you have all the resources loaded in Gateway II's case, you can right click on one of the files, and click Copy > Copy all as cURL (cmd), paste that into a text file, save it into the same folder as that cURLsDownloader.bat (make sure you extracted it) and enter the text file name into the prompt you get when you run said batch file, and it'll download all the links for you.

This isn't to say you shouldn't be cautious, though. There are certain games out there that only load these resources when you need them. One example is a few Nitrome games; they will only load the XMLs that contain their level data once you get to them; therefore, you need to play the entire game, end-to-end, before you can safely copy the cURLs into a text file and download them. Sometimes, and only sometimes, you can take apart the SWF with a decompiler and check for all the files you need, but this is never a guarantee (and that goes beyond the scope of this tutorial). There are others as well, including some games that will only have an ending loaded from external files. You can never be 100% sure, without playing through an entire game, whether or not this is the case.

With that said, it is easy to miss this kind of thing when you're working on games, which is why the golden rule is to always, ALWAYS test in Flashpoint Core before you go submitting a game. Preferably with your internet cut off and your internet cache files wiped (there is a convienient option to do this in the Redirector's File menu, you should do this every time you curate a new multi-asset game). If you have the launch command set to HTTP and the game itself doesn't try to talk over HTTPS, you'll find it easy to notice when things don't load in multiple ways; the game will stop dead, or the Redirector window will throw up "404 NOT FOUND" messages next to certain file names, which you should always try to grab (if you did the smart thing of reconstructing the exact same file structure on the fake internet as the real one, you might be able to just copy and paste straight from the redirector to the real internet to grab the file in question). If the game, whether by you leaving a HTTPS in the launch command or by the game itself trying to, ends up trying to talk over HTTPS, you'll see something along the lines of this following line in the Redirector:

(404 Not Found) GET http://ocsp.comodoca.com/MFIwUDBOMEwwSjAJBgUrDgMCGgUABBR64T7ooMQqLLQoy+emBUYZQOKh6QQUkK9qOpRaC9iQ6hJWc99DtDoo2ucCEQC66MA/sMbTbAk54Fmbn6wF

Basically though, there's no "end all be all" solution to the multi-asset problem that isn't constant vigilance. If it makes you feel better, in the absolute majority of cases since this project has started that we've observed, if a game lets you get through more than one level without loading another asset, you'll generally be okay to assume that there's no more assets to be found, but again, this is never a guarantee, and you should always test as much as you can.

Wrapping It Up

Now that we have it all working as expected, its time to send our game into the proper curation channels. This page here tells you everything you need to know about our curation format, and how we use it to pack up and send in games for adding into the master copy. You'll need a content folder, that you lay out with the game files the same way you did with Flashpoint Core, a logo and a screenshot, taken from the game itself, which you can also do in Core, and a meta.txt that describes the game with as much information as possible; again, information on how this should all be set up is on that page. Once you have a proper curation ready, the curation lounge on our Discord is open for you to submit to see if you got it right. If you did, you'll have a trial curator role in no time, which you can use to start sending in submissions.