How To Download Html5 Games To Play Offline __FULL__
Joelle Ridgeway
I am currently using VideoJS for playback; however, my question is not implementation specific. When I attempt to use the VTT files, I get a cross-origin error saying that the files cannot be used. (This depends on the browser though, as IE 10 seems to play just fine while Firefox and Chrome throw the error.)
Use a JavaScript video player to dynamically update the DOM to display the subtitles. That was my previous approach, still available in this GitHub Gist. I used a heavily modified version of VideoSub v0.9.9 by Thomas Sturm.
If you want to make this work offline and not monkey with Chrome flags, option B is probably your best bet. It would require an installation of some kind, but there are countless ways to set up a simple webserver across platforms.
However, as you have already noticed, subtitles won't display when this HTML file is opened locally. That's because of the local link to the VTT/SRT file. If your goal is off-line usage without the need of hosting the subtitle files in a server, then the best solution is to convert those links to embedded base64 content. For such, I wrote a small script in Node.js, which does the job for all local subtitles linked in an HTML file. The script is here:
Many years ago when Financial Times piled a load of cash in to the web they worked on offline support for assets and use various combinations of local storage and more advanced browser db storage, they got it working but its not for the faint-of-heart, it involved all sorts of trickier involving what gets stored where and compressing those assets to fit within browser limits for offline storage. You might find some good articles detailing their approach with the good news that most of these apis are now more advanced and stable in browsers.
But consider that a H5 game may use dynamically constructed resource requests so there is no guarantee that all assets are knowable upfront, or via a crawler. So another option is to hit F12 on Chrome, play the game throughout and note all the assets that appear in the the "Sources" tab. Save each. Also consider permissions - check whether you have the right to store an offline version of such files.
As it's just a quiz, all you really need do is play the game once and write down the questions and answers to play offline. In this case the data XML is stored at: -direct.co.uk/resources/quiz-busters/quiz-busters-game.aspx?game_id=148264. But I doubt that'll work due to session management, plus see point 3.
It is possible. Being a Flash game it is downloaded from the internet, usually saved locally to cache, then run in the local Flash player. This particular example is more complex because of the run-time loading of subsequent assets, their hard-coded urls and the session management of the host. Possible yes, worthwhile no.
I wanted to save some html5 games on the laptop for my little brother to play when he's out of wifi range. I downloaded all the files and changed the paths so that no erros appear.Now when I open index.html a blank page oppen with a loader gif and nothing else loads. I dont understand why? No errors are thrown. The only error is the one that it cannot find ads (when loadvoyager is called). I tried to comment it, still nothing positively happends.This is an archive of the game: =0
My mom doesn't play much, but she likes some of these simple html5 games. I would like to find a simple way to archive these html5 games locally so that she can play them offline at any time, in case the publisher takes them offline at some point.
I've been looking for a way to make my HTML5 game-in-progress be able to be played offline after the player has pulled the game up at least once, and I've found various methods like Appcache, a manifest file, Service Workers, and other methods like making it a Chrome Web Store app or even an .exe file. But most of these have been confusing and I'm not sure which to use. What are the pros and cons of each method and which one would likely be played the most people and be the easiest to use?
Edit: By "offline" I mean that the after the player plays my game at least once and closes the browser say they lose internet access, they can just open the browser and go to the URL of my game again with it working and not show a "no internet" error.
Someone posted on r/webdev asking whether it would be possibleto archive a certain HTML5 game locally for offline play, similar to how folksused to archive Flash games by downloading the embedded .swf file, back inthe early days of the Web. None of the other answers seemed particularly helpfulat the time, so I decided to take a stab at it.
I tried to use Node JS to pack my HTML5 to 32 and 64 bit exe but sound of the mp4 doesn't work
I tried to drag and drop Node webkit to my HTML5 directory and play the HTML5 via Node.exe but sound of the mp4 doesn't work.
I tried to use electron to make package.json and pack the file but it said error "cjs.Bitmap is not a constructor".
Is there any simple way to make HTML5 that publish form adobe animate can play offline?
I just want it to "click and play" I'm ok if it will be a bunch of folder or large file size when send to people.
Thank you for reading.
Because the Web Audio API offers developers direct control over the AudioBuffer, you can now convert data formats on-the-fly and feed them directly to the Web Audio API for playback. For example, if you encode an MP3 file as a Base64 string, you can then decode it to an ArrayBuffer and convert the raw audio data.
I was working on an all purpose in browser audio player recently, and I did something similar with the fileReader api. Using a file input box , I passed the data url into an audio element as source and it played just fine.
OpenSSL to do the encoding never occurred to me, great idea.
First up on our list is the Filesystem & FileWriter API. The Filesystem API is a virtual filesystem that allows you to create, read, and write files to a section of your local filesystem. This would enable you to store your HTML, CSS, and JavaScript files so that the user would have access to them offline.
As you can see, the Filesystem API is only supported by about 35% of browsers with webkit browsers being the only supporter. This makes the Filesystem API a poor choice for making your game playable offline.
Although the Web SQL API is supported by about 54% of browsers, the main problem is that the W3C has stopped maintaining the specification for it and is probably not going to pick it back up. So until they do, this is also a poor choice for making your game playable offline.
IndexedDB is supported by almost 59% of browsers with good support even in Internet Explorer. However, it lacks support in the mobile browsers, making this another poor choice for making your game playable offline.
Next up is the Application Cache. The Application Cache (or appcache for short) is a method for making your files available offline by telling the browser to cache them on the client. This would allow you to cache all of your HTML, CSS, and JavaScript files as well as your images and audio files for offline use.
As with appcache, Web Storage has a great browser support of almost 91% (even all the way back to IE 8) and is the recommended way of storing information to the browser. This information is even accessible while offline, so this is another great choice.
Cut the Rope has over 100 images that are needed to play the game. Of these 100 images, 44 of them are encoded in base64. The game also incorporates about 30 audio files. In total, there are about 3998KB (3.9MB) of images and 686KB of audio. The main JavaScript file for the game is 273KB (minified) and the main CSS file is 45KB (minified).
Web Storage is a great way to store information to the browser that can be accessed later, even offline. However, there are some disadvantages to using it. The first is that you are only allowed roughly 5MB of storage. The second problem is that each key/value pair is stored as a string. This means that if you wanted to store boolean values or integers, you would have to use the JavaScript function parseInt() to get them back into their desired format.
The second technique is for storing assets. In this technique, you base64 encode all of your images and audio files and store the resulting strings into local storage. The advantage to this technique is that you can store only the images and audio files the user has used while playing online.
The second reason that this technique is limited is that base64 encoded images are about 6x slower on mobile devices. This is because the image must be decoded back into its binary representation before it can be displayed. For this reason, you should be careful about which images you do encode and mainly use them for small files and CSS sprite sheets.
Web Storage is great for storing information about the game such as level data, user preferences, where the user stopped playing, and any other information about your game or user that you wanted to store. Web Storage is not great for storing your games files and assets. For this, we must turn to the appcache.
Another problem appcache presents is serving the correct assets for your user based on what the user is able to use. For example, Internet Explorer, Safari and Chrome can play .mp3 audio files, but Firefox and Opera use .ogg files, and almost all of them can play .wav files. And what if you wanted to serve smaller images based on whether the user is on a mobile or tablet device? This is hard to accomplish using appcache.
A difficulty I foresee is keeping track of which user owns which manifest and making sure they always point to that manifest. One solution you could use is force users to register to play your game so that you can keep track of their unique identifier.
Appcache, although a pain to work with, can help make your game playable offline. When using appcache, most of the time you should place all of your files into the manifest as it is currently very hard to create dynamic manifests.
8d45195817