![\"iOS](\"https://www.stelabouras.com/blog/itchio-webgl/ios-screen-orientation-lock.png\"/)
The following is a collection of improvements that can be implemented on a Unity WebGL game released in Itch.io, that allows developers to distribute their game on mobile devices without going through Apple's App Store or Google Play.
This post serves both as a cleaned-up version of my notes for future reference, but it can also help other developers having a similar interest on the subject. Also, while the post focuses on WebGL games created using the Unity engine, the techniques described below can be easily ported to any other engine that supports this in-between JS layer for allowing communication between the game and the hosted webpage.
Implementing what is being described in this post will allow players to install your WebGL game as a Progressive Web App (PWA), creating an icon on their home screen and launching it without opening their browser. Players can also be validated for their purchase via Itch API and can even be notified when an update is available!
Minor disclaimer: I haven't coded professionally in JavaScript for more than a decade, so the JS code you will see below can be quite crude. On the upside, it's just pure vanilla JS so it will be easy to port to any framework you are familiar with.
OK, let's begin!
Before we delve deeper into the technical stuff, let's address one main issue: Itch does not allow you to sell/set a price on a WebGL game. Don't fret though, as there is a way to check whether a certain Itch user has access to your game via download keys.
In the \"Distribute\" tab of your WebGL game, you can generate a number of download keys and either distribute them freely, or unlock them after users have paid for the game via your website. You can also bundle them together as a free upgrade when users purchase the desktop version of your game right within Itch!
To achieve the latter, you will have to generate a number of download keys for your WebGL game, download them locally and then upload them as \"External keys\" in the \"Distribute\" tab of your desktop game (with Key Type set to \"Other\"). This way, when a user purchases the desktop version of the game, they will be granted with a download key for the WebGL build which they can claim.
Now that we have addressed that, let's proceed!
The first thing we need to establish is that every time you push a new WebGL build, Itch generates a new webpage for that build, for cache related reasons. The existing webpage will continue to work for some time but it will get invalidated a while after the new build becomes available. This means that we need a way of always pointing the player to the latest and greatest build. Although this is not as straightforward, as it requires server-side API call(s), it's definitely feasible.
What we can do is create a webpage hosted on the game's website that serves multiple purposes:
Let's go through the list one-by-one.
There is a lot of online documentation for creating a PWA, but here are the tags that need to be included the <head> of the webpage:
<meta content="width=device-width, initial-scale=1.0, user-scalable=no, viewport-fit=cover" name="viewport"/><meta content="yes" name="mobile-web-app-capable"/><meta content="yes" name="apple-mobile-web-app-capable"/><meta content="black-translucent" name="apple-mobile-web-app-status-bar-style"/><meta content="<!-- GAME NAME -->" name="apple-mobile-web-app-title"/><link href="<!-- link to app icon -->" rel="apple-touch-icon"/><link href="<!-- link to the manifest.json file -->" rel="manifest"/>The manifest.json file is needed (although not required), in order for the game to be detected as an installable PWA. Most of manifest.json properties are self-explanatory and extensively documented. The only note I need to make here is to use fullscreen instead of standalone for the display property as this will actually make the web view extend outside the screen safe area when the game is installed. The orientation and start_url ones are also important.
In order to always fetch the latest build url, we need to use Itch's API. You can generate an API key on the Developer > API keys section of Itch user settings. The issue here is that the API documentation on Itch does not include all of the endpoints: there are endpoints that are not listed there and one of them is the one we need: /api/1/{api_key}/game/{id}/uploads.
After fetching the ID of the WebGL game from the url of the edit page of the game, we can perform a simple API request on the server that hosts the webpage of our game. Here's a simple snippet that uses server-side JavaScript to perform the request:
const uploadsURL = `https://itch.io/api/1/${process.env.ITCH_API_KEY}/game/${process.env.ITCH_GAME_ID}/uploads`try { const response = await fetch(uploadsURL, { method: 'GET' }); if (response.ok) { const uploads = await response.json(); if (uploads == undefined || uploads.uploads == undefined || uploads.uploads.length == 0) { return { statusCode: 404, body: JSON.stringify({ message: `Upload not found!` }) }; } const upload = uploads.uploads[0]; const buildID = upload.build.id; const uploadID = upload.build.upload_id; const buildURL = 'https://html-classic.itch.zone/html/' + uploadID + '-' + buildID + '/index.html'; return { statusCode: 200, body: buildURL }; } else { return { statusCode: response.status, body: JSON.stringify({ message: `Error fetching uploads ${response.status}` }) }; }}This is the main logic of the build url generator: It requests the uploads list from the API for our game, fetches the latest upload object and generates the URL based on the values of the upload and build IDs.
You can go a step further and only allow the user to fetch the latest build url after checking whether they have actually purchased the game, in order to do that you would need to create an OAuth application, allow user to login to Itch using this application and then query two more API endpoints using their access token:
As soon as the user grants permission to the OAuth application and Itch redirects back to our server with the access token, we can perform the following two API requests before trying to generate the build URL: /api/1/{access_token}/me, where the access token is used as an API key in order to fetch the user ID of that user and /api/1/{api_key}/game/{game_id}/download_keys?user_id={user_id}, where we expect that a download key will exist for that user, if they have claimed a key for the WebGL game (as we have described above).
And there you have it: We have essentially built a really simple mechanism for checking whether a player has purchased the game and a way to always fetch the latest build url for that game!
With this url we can create an <iframe> HTML object that hosts this game and load it via JavaScript, as soon as the build url is ready!
The bonus thing here is that we can communicate with the hosted <iframe>, check when the game is on its 'Main Menu' scene and request the build url again, comparing it with the current one and presenting a pop-up to the user to refresh the website as a new build is available! We will look into how we can communicate with the hosted <iframe> using the postMessage() and message event of HTML below.
There are multiple cases where the game logic might need to communicate with the hosting page, either to query certain properties of the device (is it a mobile device?), change certain properties of the DOM or even receive events from the webpage.
In order to achieve that we need to create a JavaScript bridge. You can follow Unity's guide for that. You can create a WebGL folder under the Plugins directory (Assets/Plugins/WebGL/) and create two files there:
WebGLPluginJS.csWebGLPluginJS.jslibThe .cs file holds all the [DllImport(\"__Internal\")] function signatures and the .jslib contains the JavaScript implementation.
Let's say that we want to inform our webpage that the game's main menu is visible or not.
WebGLPluginJS.cs[DllImport("__Internal")]public static extern void MainMenuShown();[DllImport("__Internal")]public static extern void MainMenuHidden();which we can call from our Main Menu's in-game logic like that:
MainMenu.cspublic class MainMenuLogic : MonoBehaviour { void Start () {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.MainMenuShown();#endif } void OnDestroy() {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.MainMenuHidden();#endif }}The actual JavaScript methods can take advantage of the postMessage HTML API:
WebGLPluginJS.jslibMainMenuShown: function() { parent.postMessage("MainMenuShown", "*");},MainMenuHidden: function() { parent.postMessage("MainMenuHidden", "*");},Here we post a message to the parent webpage which is the page the build URL is hosted as an iframe, namely our PWA webpage. On the PWA webpage JavaScript we can have something like that:
window.addEventListener("message", (e) => { const data = e.data; if (data == "MainMenuShown") { // Execute the check for updates logic and // present the "Update available" popup in HTML } else if (data == "MainMenuHidden") { // Hide the "Update available" popup in HTML }},false);Alternatively, we can reverse the logic and have the game query (using the JS bridge) the hosting page on whether a new build is available and then present an in-game popup.
An easy way to pause the game when user taps outside the WebGL container or navigates to another website, is to use the Page Visibility API.
WebGLPluginJS.cs[DllImport("__Internal")]public static extern void RegisterVisibilityChangeEvent();WebGLPluginJS.jslibRegisterVisibilityChangeEvent: function () { document.addEventListener("visibilitychange", function () { SendMessage("GameLogic", "OnVisibilityChange", document.visibilityState); }); if (document.visibilityState != "visible") { SendMessage("GameLogic", "OnVisibilityChange", document.visibilityState); }},In the Unity scene, create a GameObject named \"GameLogic\" (or change that to whatever you want) and in one of its attached scripts declare the \"OnVisibilityChange\" method. Additionally call the RegisterVisibilityChangeEvent() from its Start() method.
GameLogic.csvoid Start() {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.RegisterVisibilityChangeEvent();#endif}void OnVisibilityChange(string visibilityState) { // Custom logic}If the game already reacts to the OnApplicationFocus event by Unity (for example by displaying a pause screen), the implemented OnVisibilityChange() method can simple call OnApplicationFocus() directly which will execute the same logic.
GameLogic.csvoid OnVisibilityChange(string visibilityState) { OnApplicationFocus(visibilityState == "visible");}Generally speaking, if the game has been created with the option to react correctly to resolution changes and more specifically designed to support both vertical and horizontal orientations of mobile devices, then everything might already be operating correctly.
If, on the other hand, the game supports only a specific orientation, then locking the screen orientation of the screen sounds like the way to go.
Sadly, even though a method for locking the orientation exists in the Screen API, it's not supported yet by mobile browsers. In iOS, for example, this feature is hidden behind the Safari Feature Flags (as seen below), so the only option left here is to inform the player than only a certain device orientation is supported, by detecting and reacting to screen orientation changes.
The following snippet on our PWA webpage assumes that the game only supports portrait orientation on mobile devices:
isMobile = () => { return /mobile/.test(navigator.userAgent.toLowerCase());};isLandscape = () => { return isMobile() && /landscape/.test(screen.orientation.type.toLowerCase());};toggleLandscapePrompt = (enable) => { // Toggles landscape prompt visibility based on the value of the // `enable` flag.};loadGame = () => { // Queries our server for the build url and creates the `iframe` // containing the link to the Itch.io page hosting the Unity WebGL // game.};window.addEventListener("DOMContentLoaded", () => { // Listen to orientation events screen.orientation.addEventListener("change", (e) => { let landscape = isLandscape(); toggleLandscapePrompt(landscape); if (!landscape) { loadGame(); } }); // If the game only supports portrait orientations, do not allow // it to be loaded if player's device is initially held sideways. if (isLandscape()) { toggleLandscapePrompt(true); } else { loadGame(); }}In WebGL, storing data in PlayerPrefs will not persist over page reloads. For this to happen, PlayerPrefs must be replaced with a different way of storing persistent information, which in most cases is the localStorage API. There's a caveat here: For the approach we are exploring in this article where we create a page that generates an iframe which points to the WebGL build on Itch.io, the localStorage API approach won't be enough, as it will store the data on the Itch.io page and if player has added the page as an web app to their home screen, this data will not persist over web app relaunches.
Firstly, let's tackle the simple scenario where a PWA webpage like the one we have above does not exist and we only aim to store player preferences persistently when Itch generates a new url because of a new build: For this to happen we use the localStorage API and we prefix our PlayerPrefs keys with a unique (to our game) string (PREFIX_KEY), which will allow our keys to co-exist with any other localStorage keys that might already exist for the Itch.io domain.
Assuming there's a centralized logic responsible for storing information for your game (for example: high scores, currency etc), the logic can me modified to work differently for WebGL builds.
PlayerPrefsManager.cspublic static class PlayerPrefsManager { private const string PREFIX_KEY = "<unique_key>"; public static string PrefixKey(string key) { return PREFIX_KEY + key; } public static void SetString(string key, string data) {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.SaveData(PrefixKey(key), data);#else PlayerPrefs.SetString(key, data);#endif } public static string GetString(string key, string defaultValue = "") {#if UNITY_WEBGL && !UNITY_EDITOR return WebGLPluginJS.LoadData(PrefixKey(key));#else return PlayerPrefs.GetString(key);#endif } // NOTE: This can be extended to `GetFloat` / `SetFloat`, `GetInt` / // `SetInt` methods. public static void Save() {#if UNITY_WEBGL && !UNITY_EDITOR // no-op#else PlayerPrefs.Save();#endif } public static bool HasKey(string key) {#if UNITY_WEBGL && !UNITY_EDITOR return WebGLPluginJS.LoadData(PrefixKey(key)) != string.Empty;#else return PlayerPrefs.HasKey(key);#endif }}WebGLPluginJS.cs[DllImport("__Internal")]public static extern void SaveData(string key, string data);[DllImport("__Internal")]public static extern string LoadData(string key);WebGLPluginJS.jslibLoadData: function(yourkey){ var returnStr = ""; if (localStorage.getItem(UTF8ToString(yourkey)) !== null) { returnStr = localStorage.getItem(UTF8ToString(yourkey)); } var bufferSize = lengthBytesUTF8(returnStr) + 1; var buffer = _malloc(bufferSize); stringToUTF8(returnStr, buffer, bufferSize); return buffer;},SaveData: function(yourkey, yourdata){ localStorage.setItem(UTF8ToString(yourkey), UTF8ToString(yourdata));}Now, if we want to ensure that the PlayerPrefs persist not only across builds but also be synced on our PWA webpage, then we need to perform an extra step: When players install the PWA app, whatever is stored in the localStorage of the hosted <iframe> of that webpage will not persist, which means that we will want to store the information to the localStorage of the PWA webpage and not of the iframe. In order to do that we can use postMessage again to sync the state between the build webpage and our PWA webpage. We can start by storing the PlayerPrefs on a custom object and when the PlayerPrefsManager.Save(); method is called, sync this object via postMesage, to the parent PWA webpage. We can also add an optional #installed hash in our generated build url which can differentiate between the webpage being hosted on the game website on Itch or on our PWA webpage where we fully control the logic.
Here is how the code can be modified to account for that:
PlayerPrefsManager.cspublic static class PlayerPrefsManager { public static void Save() {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.SyncToParent();#else PlayerPrefs.Save();#endif }}WebGLPluginJS.cs[DllImport("__Internal")]public static extern void SyncToParent();WebGLPluginJS.jslibLoadData: function(yourkey){ var returnStr = ""; if (window.location.hash == "#installed") { if (window.parentLocalStorage[UTF8ToString(yourkey)] != undefined) { returnStr = window.parentLocalStorage[UTF8ToString(yourkey)]; } } else { if (localStorage.getItem(UTF8ToString(yourkey)) !== null) { returnStr = localStorage.getItem(UTF8ToString(yourkey)); } } var bufferSize = lengthBytesUTF8(returnStr) + 1; var buffer = _malloc(bufferSize); stringToUTF8(returnStr, buffer, bufferSize); return buffer;},SaveData: function(yourkey, yourdata){ if (window.location.hash == "#installed") { window.parentLocalStorage[UTF8ToString(yourkey)] = UTF8ToString(yourdata); } else { localStorage.setItem(UTF8ToString(yourkey), UTF8ToString(yourdata)); }},SyncToParent: function() { if (window.location.hash != "#installed") { return; } parent.postMessage({ 'localStorage': window.parentLocalStorage }, "*");}and on our PWA webpage we can modify the message listener to also listen for the 'localstorage' messages and update its own localStorage accordingly.
window.addEventListener("message", (e) => { var data = e.data; // ... else if (typeof data == "object" && data.localStorage != undefined) { for (const [k, v] of Object.entries(data.localStorage)) { localStorage.setItem(k, v); } }},false);We also want our PWA webpage to sync its contents with the game from its localStorage when the game loads. We can add the following logic when constructing the <iframe> to be added to our webpage and before inject it:
// assuming that we have constructed the build_urlvar iframe = document.createElement('iframe');iframe.setAttribute('allowtransparency', 'true');iframe.setAttribute('webkitallowfullscreen', 'true');iframe.setAttribute('mozallowfullscreen', 'true');iframe.setAttribute('msallowfullscreen', 'true');iframe.setAttribute('allowfullscreen', 'true');iframe.setAttribute('frameborder', '0');iframe.setAttribute('scrolling', 'no');iframe.setAttribute('allow', 'autoplay; fullscreen *; geolocation; microphone; camera; midi; monetization; xr-spatial-tracking; gamepad; gyroscope; accelerometer; xr; cross-origin-isolated; web-share');iframe.id = 'game';iframe.src = build_url + '#installed';iframe.onload = () => { let storageDict = JSON.parse(JSON.stringify(localStorage)); document.querySelector('iframe').contentWindow.postMessage({ 'localStorage': storageDict }, '*');};document.body.appendChild(iframe);On the HTML file that Unity generates that actually hosts our game we can add the following:
// Sync localStorage from parent framedocument.addEventListener("DOMContentLoaded", () => { window.parentLocalStorage = {}; window.addEventListener("message", (e) => { let data = e.data if (typeof data == "object" && data.localStorage != undefined) { for (const [k, v] of Object.entries(data.localStorage)) { window.parentLocalStorage[k] = v; } } });});Given that we now have an easy JS bridge between our game and the build / PWA webpages, we can have some fun as well! One cool thing we can implement is a way to change the background color of the hosted webpage in order to match the color of the scene! You can just change the background color of the build webpage or propagate the change all the way to the PWA webpage.
GameLogic.cspublic void ChangeBackgroundColor(Color color) {#if UNITY_WEBGL && !UNITY_EDITOR WebGLPluginJS.ChangeBackgroundColor(ColorUtility.ToHtmlStringRGB(color));#endif}WebGLPluginJS.cs[DllImport("__Internal")]public static extern void ChangeBackgroundColor(string hexCode);WebGLPluginJS.jslibChangeBackgroundColor: function (hexCode) { var hexCodeString = UTF8ToString(hexCode); document.documentElement.style.backgroundColor = "#" + hexCodeString; document.body.style.backgroundColor = "#" + hexCodeString;},and there you have it!
Given that a PWA is essentially a webpage, we can leverage more APIs to improve the user experience. Things like service workers to perform tasks in the background, offline support and more, can be just the tip of the iceberg!
Below are references I have collected during my research that you might find useful:
Every now and then we learn about a new asteroid passing really close to Earth, usually within a couple of hours of it being detected. And right after all those 'the end is nigh' click-bait news articles, we are reassured by NASA that there is no need to panic, with a link to their Eyes on Asteroids website.
News like that, made me think of ways we can have a simple up-to-date and easy to access view for those... close encounters.
Fortunately, NASA already offers an API that we can use in order to retrieve information on close-approach asteroids and comets: The Small-Body Database (aka SBDB) Close-Approach Data API 1. Yup, it's a mouthful.
The API is well-documented and offers a plethora of query parameters we can use, like filtering by the distance of the small bodies in relation to Earth (or any other body 2), by date, as well as controlling which parameters are going to be available on the results, like the full name of the approaching small body.
Given that I have been using the iOS shortcuts a lot lately, I have created a small \"Is the sky falling on my head?\" iOS shortcut that upon being triggered, displays the closest upcoming small body, offering three links for more information:
I have also created an automation and extra helper shortcut: The automation fires once a day (when I wake up) and triggers the helper shortcut that just returns the distance of the closest small body.
If that distance is lower than a threshold I have already set (I found that 1.000.000 km is a nice threshold), then the automation runs the main 'Is the sky falling on my head?' shortcut that reports the information, otherwise I get a message that our planet is safe...for now!
I admit that it is really tempting to try and cram all the information reported by NASA's API to a single report (parameters like the body's velocity, diameter, sigma are all interesting) but I have intentionally tried to keep the report as simple as possible, while offering links for more information.
Here's an example report from the other day:
![\"An](\"https://www.stelabouras.com/blog/is-the-sky-falling-on-my-head-shortcut/shortcut.jpg\"/)
Looks like we are safe!
You can download and tinker with those shortcuts below.
Download 'Is the sky falling on my head?' Shortcut
Download 'Is the sky falling on my head? [HELPER]' Shortcut
How many times have you tried accessing the settings of an iOS application on your device, but just the thought of scrolling through this really long list of installed applications in the Settings app makes you abandon all hope?
Maybe I am the only one answering positively to the above rhetorical question, but I am surprised that this particular user experience still feels like a chore.
Although I haven't been using Android as much as I do iOS, I find it really easy that on Android you can access the application settings (called \"App info\") just by long tapping on the application icon on the Android home screen.
![\"The](\"https://www.stelabouras.com/blog/ios-shortcuts/android-app-info.jpg\"/)
It's so liberating that it made me wonder why there is no such option on iOS, when force-tapping on an application icon on the iOS Home Screen.
Fortunately, UIKit provides us with the APIs necessary in order to build such an interaction ourselves. So below you can find a simple way to implement this interaction in the applications you develop (I had to clarify that so that the post doesn't read like an end-user guide where anyone can 'hack' the iOS to do something it cannot).
There are only three key components we need in order to build this kind of interaction:
shortcutItems 1 property (iOS 9.0+), that allows us to define custom home screen shortcuts programmatically.openSettingsURLString 2 (iOS 8.0+) and openNotificationSettingsURLString 3 (iOS 16.0+) properties, that allows us to navigate to the respective view of the native Settings application.gear (iOS 13.0+) and bell.badge (iOS 14.0+) SF Symbols 4, allowing us to set the proper icon to those shortcuts that 100% match the iOS style.Based on the above, if we only want to provide a shortcut to the main settings of the application, the application can just target iOS 13.0+ but if we also want to provide a separate shortcut to the notification settings, then the application must target iOS 16.0+. In any case, given that the iOS 18.0 release is just around the corner, I don't think this is a limiting factor.
Using those components, I have created a simple Swift sample application on GitHub that showcases this interaction, producing the following contextual menu when force-tapping the application icon on the iOS Home Screen:
![\"The](\"https://www.stelabouras.com/blog/ios-shortcuts/ios-shortcuts.jpg\"/)
I will start implementing this interaction to my released applications soon, as I find it really helpful to be able to access the application's settings and notification views with just one tap!
Some (minor) caveats:
It has been a while since I have started the multi-year process of de-Googling myself. It is nowhere near close to the finish line, but I have taken a few steps towards it.
The past few months I have been trying to find a good YouTube alternative. I am already a subscriber on Nebula 1 (a good, albeit pretty light on content competitor to YouTube) and I am trying my best to support some of my favorite YouTube creators over on Patreon 2.
For YouTube content, I have recently discovered Invidious 3, which is a front-end alternative, meaning that the videos are still hosted on and served by YouTube (note: there are also alternatives to Invidious, like Piped 4). Invidious is based on public instances that other people have already set up, and given the nature of its implementation, it is locked on a cat & mouse game with YouTube, where the logic can break everytime Google changes something on their website 5. That said it is a rather good alternative: It is stable (minus a few hick-ups when something breaks by Google), it has an active community, there are a lot of different integrations (browser extensions 6, applications 7 etc) and you can always spin up your own private instance if you so desire!
In the spirit of trying to move away from Google products, I have built this small Shortcut for MacOS / iOS devices 8. Its purpose is simple: Every time you try to watch a YouTube video either on the YouTube website or the YouTube mobile application, you have the option to get redirected to the embedded version of the same video on an Invidious instance of your choice.
On the Shortcut setup (Apple calls that 'Import Questions'), I have added the option to specify the Invidious instance of your choice as well as change the auto-play flag. If you leave the Invidious instance field blank, you will be redirected to the GDPR compliant \"youtube-nocookie\" embedded URL that contains no ads and no tracking. The auto-play flag controls whether the video will start auto-playing (muted, to comply with the auto-play policies 9) as soon as it loads, or not.
On top of that, by viewing the videos this way you can use the Picture-in-Picture (PiP) feature of iOS without being a YouTube Premium subscriber! đ
You can find a link to the shortcut below. After adding it to your MacOS / iOS device you can answer the Import Questions and you are ready to go!
Download YouTube Redirect Shortcut
...or how to write a simple static website generator in a day.
Ten days ago I launched a simple project called 'The Unity Library'.
The Unity Library is a small, curated collection of Unity related tutorials, posts and tips that I kept for personal reference, which I decided to make public as a means of giving back to this amazing community.
Here's the announcement originally posted on Twitter:
Over the past few months, I have been h̶o̶a̶r̶d̶i̶n̶g̶ collecting and organizing Unity related posts, shaders, tutorials and tips from game developers and designers I follow, respect and look up to.
Although this was created just as a personal reference, I have decided to build a public website & host this information for anyone interested in taking a deeper dive in subjects like Raymarching, Lava or Snow rendering, Tool shading, Sea and Water shaders and many more.
Let me emphasize this: This project wouldn't be possible without creators like AlanZucconi, catlikecoding, Cyanilux, febucci, HarryAlisavakis, TheAllenChou, minionsart, andre_mc, totallyRonja, ManuelaXibanya, DanielJMoran and so many others.
If you happen to be a Unity game developer, I would strongly suggest following the aforementioned accounts; I have learned so much from those people over the past few months and I really want to thank them for sharing their knowledge.
Here's the link to the project: https://unity.stelabouras.com
I hope you like it. This library will be updated with new links every time I find something interesting and useful!
Finally, I want to dedicate this project to my beloved grandpa, who recently passed away. â„ïž
The response was quite overwhelming and definitely disproportionate to the amount of time I spent building it! đ„°
The whole idea started when I noticed that a collection of Unity-related links I was maintaing, was growing significantly in number on my Linkpack folder and I needed a separate searchable interface which I could consult often without having to go through my files. So I began grouping those files into folders and ended up creating a simple parser script to generate the library structure.
I reused some simple logic already implemented in Python on the server-side of Linkpack, so that I could extract the necessary information from the file structure into a JSON format. The script was aptly named the ...\"Librarian\", as it was tasked with traversing the whole folder, parsing the files, extracting the links, checking the Open Graph tags of the website, storing the url in the Wayback Machine, and finally storing the whole library JSON structure into a separate file.
After that, I created a simple generator script that was responsible for creating the whole static website from that JSON script, by generating the proper folder structure, building the HTML files, copying the static CSS and JS I have coded to style the pages correctly and getting the whole JSON structure loaded in Javascript so that the whole website is searchable.
For hosting the project, I picked the trusted Netlify service, the same service this very blog is hosted at!
Overall 'The Unity Library' was a rather fun little project and something that I keep improving those days whenever I have a chance.
Update! The Unity Library is now open source under a MIT license! You can find the project at Gitlab where you can file an MR if you have an interesting link that can be included at the library!
", "summary": "...or how to write a simple static website generator in a day. Ten days ago I launched a simple p...Continue reading \u2192", "date_published": "2020-03-15T00:00:00Z", "date_modified": "2020-03-15T00:00:00Z" }, { "id" : "https://www.stelabouras.com/blog/airplane-safety/", "url": "https://www.stelabouras.com/blog/airplane-safety/", "title": "Airplane Safety - My most personal project", "content_html": "This is the story of Airplane Safety, one of my dad's personal projects and also his last.
While discussing the project around June 2017, he asked me how could we communicate this idea to the right people, so I suggested translating and releasing it to the Web.
I remember saying to him: \"Let's release it once I come back from my holiday vacations\".
If only I knew.
My dad passed away suddenly -without any warning or sign of illness- at the age of 59, the day I was returning home from my vacations in August.
Since then I have tried multiple times to start working on this project, but failed to do so, as grief was taking over of me every time. It is only lately that I have managed to muster enough courage to begin translating it.
As you will notice by the abstract, my dad was a high-school Physics professor and even though he adored his job, he was also interested in expanding his knowledge by attending online courses on advanced Physics concepts, was eager to help students by providing free after-school classes and loved coming up with ideas on how certain technologies could be improved.
I remember him telling me that he had also drafted some thoughts, way back when, of a system similar to the one implemented by some cars manufacturers today, able to detect movemevent via sensors and stop the car before an accident could occur.
The idea behind this project, though, was one of my dad's biggest concerns: How can the aircraft passengers and crew be saved, even under a severe mulfunction event.
In Airplane Safety you will not find any mathematic formulas or detailed schematics, but a rather high level approach of the issue, which I think is the best way to convey any ideas at an early stage.
My dad wished to release this document for free for anyone to read, just in case those ideas made it to some airplane safety specialists.
For this reason, I am open sourcing all of his original notes (scanned and in docx format in Greek), as well as the translation in multiple formats (PDF, epub, LaTeX, Markdown) under the MIT License.
I could go in great lengths about my dad's character, how he was the most beloved teacher, co-worker, husband and father, but I will just finish this post by saying this one last thing:
This is for you dad, I love you.
", "summary": "This is the story of Airplane Safety, one of my dad\u0026#39;s personal projects and also his last. While ...Continue reading \u2192", "date_published": "2018-03-24T00:00:00Z", "date_modified": "2018-03-24T00:00:00Z" }, { "id" : "https://www.stelabouras.com/blog/hearth/", "url": "https://www.stelabouras.com/blog/hearth/", "title": "Hearth: Decentralized Website Publishing", "content_html": "Last week, me and Stavros introduced our new side-project to the world, Hearth.
Hearth aims to be your go-to website publisher for the decentralized web, harnessing the power of IPFS.
Having built Eternum, an IPFS pinning service, we were trying to find use cases where IPFS could be useful to a larger audience.
Being an active Dropbox user, I was really disappointed when the Public folder was disabled earlier last year.
Dropping a small static website into your Dropbox Public folder and being able to send a link to it felt really great for sharing prototypes and experiments. Sadly, by sunsetting this feature, it was no longer possible to publish websites without having to deal with different services and web UIs.
That's pretty much how the idea for Hearth was born: We wanted to have a simple desktop app that will run IPFS as a daemon and replicate the Dropbox file sharing experience, without a centralized authority. That means, sharing links to your files from your desktop and also serving mini websites while doing so.
Stavros wrote a Rust console app that interfaces with the IPFS daemon, providing an API for requesting links to your files on the Hearth folder. I wrote a MacOS menu app with a Finder Sync extension in Swift that dealt with the UI layer and interfacing with the Finder app. In case you are interested to take a look under the hood, both of the apps (the Rust daemon and the Swift MacOS app) are open source.
I also had the pleasure of designing the app icon and website using Sketch, and I am really happy with the results. SVG animations -when used subtly- can be quite pleasing to the eye.
Although there have been some challenges in every layer involved (Rust being...Rust, MacOS integration issues and IPFS stability), we have come to a point where Hearth is now quite robust and -with its latest 0.0.3 version- able to auto-update itself using the awesome Sparkle library.
Building Hearth was quite an enjoyable experiment! As Hearth is my third Swift project (Pastery for Xcode and WSH LST being the first and second respectivelly), it now feels great to develop mobile and desktop apps using Apple's new language. On top of that, having to deal with a new technology like IPFS made the whole effort way more attractive.
We are still in talks with the IPFS team to iron out the timeout issues that may occur when trying to access a generated hash and we are also looking at the rest of the OS releases. If you want to contribute in any way, you can create an issue in the Hearth repo.
", "summary": "Last week, me and Stavros introduced our new side-project to the world, Hearth. Hearth aims to be...Continue reading \u2192", "date_published": "2018-03-15T00:00:00Z", "date_modified": "2018-03-15T00:00:00Z" }, { "id" : "https://www.stelabouras.com/blog/reboot/", "url": "https://www.stelabouras.com/blog/reboot/", "title": "Reboot.", "content_html": "Six years.
Six freaking years.
That's how long it took me to write a new post.
This website was collecting dust for a really long time, but not anymore!
Lots of things have happened during this period, both professionally and personally, and I will try to keep a -somewhat- up-to-date diary from now on, starting with the reboot of this very website.
The old Tumblr backend was not as straight-forward of a blogging experience as I was wanting it to be, so I figured it was time to move on.
This new website is powered by a static CMS called Lektor, which also powers some of my side-projects, and it's hosted in Netlify, which is hands down one of the best services I have used for quite a long time.
The website is really crude at the moment, so apologies for any weird issues happening here and there. I will also add things like an RSS feed, a Google crawler-friendly sitemap and probably comments, but I believe this first version is a good start.
Thanks for stopping by!
", "summary": "Six years. Six freaking years. That\u0026#39;s how long it took me to write a new post. This website was c...Continue reading \u2192", "date_published": "2018-03-09T00:00:00Z", "date_modified": "2018-03-09T00:00:00Z" }, { "id" : "https://www.stelabouras.com/blog/2012-resolutions/", "url": "https://www.stelabouras.com/blog/2012-resolutions/", "title": "2012 resolutions", "content_html": "I turn 26 today and it's about time I release my resolutions for 2012.
But first let's review the last year's resolutions:
The first three were a success. I lost 32kg in 2011 (in 5 months) following the advice of Tim Ferriss (4 Hour body) plus I've been exercising regularly the last 4 months (gym) and I learned to eat better & healthier.
Happy to report that this one was also a success! After visiting Scotland (and High Lands) this summer, I scored another trip abroad in Berlin, Germany for Google Developers Day in November.
I just didn't pursue this one, I think I will never be a \"coffee\" guy, but I must admit that lately I really enjoy drinking tea.
I quit playing WoW! I decided to stop after lots of years, partly due to disappointment from Blizzard's way of releasing content and due its time-sucking nature of it. Also I stopped playing online games (Call of Duty, Battlefield) in general, although this was not intended. From the other hand I am really active in gaming: I finished two big titles in 2011 (Deus Ex and Skyrim), I keep tabs with everything gaming related and I am really looking forward to play all the other games I have in my library!
Somewhat of a success: In 2011 I developed (and still developing) Analytiks, I launched some mini projects (HTML5 oriented and a Google Reader one) started a small gaming blog and I begun contributing on what became Soundbeam, the first iOS app of Evil Window Dog studio we \"founded\" with my buddy Petros.
I can't say I have met my standards in this one: I was really focused on iOS programming in 2011, which totally overshadowed any other language/technology I wanted to get involved with. Hopefully this will be fixed this year.
That's an ongoing process :) I will try harder this year, promise!
Now let's see the new resolutions. I divided the list into to separate sections: Personal stuff and Work related. Those two blend in many ways but I didn't want to create a huge list and never complete any of my targets.Â
Personal Stuff
Work Related
That's it! They may seem a few but rest assured, they are quite a task!
What's your resolutions for 2012? :)
", "summary": "I turn 26 today and it\u0026#39;s about time I release my resolutions for 2012. But first let\u0026#39;s review the...Continue reading \u2192", "date_published": "2012-01-29T00:00:00Z", "date_modified": "2012-01-29T00:00:00Z" }, { "id" : "https://www.stelabouras.com/blog/minecraft-on-the-cloud/", "url": "https://www.stelabouras.com/blog/minecraft-on-the-cloud/", "title": "Minecraft on the cloud!", "content_html": "Update: I have found (after posting this guide) that there is already a pretty well written tutorial in Minecraft Wiki, so you might wanna check this out too!
Well, sort of! I mean, title is quite catchy, isnât it?
The following piece is a quick tutorial of how you can both save and sync through multiple machines, your Minecraft worlds on the cloud (Dropbox). Think of it this way: It will operate almost transparently (except those Dropbox Growl notifications which can be turned off) just like Steam Cloud.
I have tested the following steps and I can assure you that the process I describe below works like charm between two different MacOSX systems, but I guess it can be easily extended to Windows machines too - giving that the save game architecture is the same for both OSes.
So, letâs begin with the prerequisites:
If you are installing Minecraft for the first time
Open the terminal (/Applications/Utilities/Terminal.app) and type the following:
Donât forget to replace [path to your Dropbox directory] and [your MacOSX username] with your information (thatâs where your basic understanding of Unix command line is needed)
If you already have Minecraft installed and you want to move your save games to the cloud
Open the terminal (/Applications/Utilities/Terminal.app) and type the following:
Donât forget to replace [path to your Dropbox directory] and [your MacOSX username] with your information (thatâs where your basic understanding of Unix command line is needed)
Thanks makrp for the idea ;)
", "summary": "Update: I have found (after posting this guide) that there is already a pretty well written tutor...Continue reading \u2192", "date_published": "2011-09-17T00:00:00Z", "date_modified": "2011-09-17T00:00:00Z" } ] }![app icon](\"https://hearth.eternum.io/mac_icon.png\"){kind=link}