lsof -i
: 8081
then kill [process pid]
So say you want to build a game in ReactJS and upload it to itch.io. If you started your project by running
npx create-react-app
, then ran npm run build
, zipped up the folder, then uploaded it to itch.io, you
will see a result of something like this:
So how do you fix this? The solution is, thankfully, quite simple. Go into your package.json
and add the following line after the
version number:
"homepage": ".",
Then simply rebuild the project, upload it, and the results should be as follows:
Hopefully this has helped you if this was a problem you encountered.
ReactJS is certainly far from being a common framework used for online games, but there are a fair few examples of great React games to be found on itch.io. Here are a few I liked:
I used a simple JavaScript game engine called KaboomJS. I have nothing but praise for this engine. It's super simple to get into, with a fantastic website detailing its API with dozens of examples to guide you. It being JS is a massive boon to me personally since it means its easy to develop using VSCode, as opposed to something bulky and slow like Unity, and there's a huge wealth of tutorials and libraries for JS that other game engines lack. The engine is, admittedly, a bit limited, with effectively no physics to speak of, but for the simplistic arcade games I'd choose to develop in a game jam, it is as perfect as can be.
My result of the jam was a hectic bullet hell-like space shooter called Triple Threat. It got a surprising amount of praise; a lot of people said it was an interesting concept and quite fun once they got the hang of the controls, and of course many people praised the fantastic music and sound in the game. The greatest compliment I got was knowing a few people were able to smash my very own highscore - one got a monumental score of 560, well over double what I ever achieved at my own game!
After the jam, I cleaned it up a little, responding to some player feedback regarding the controls and implementing music and SFX mute button for accessibility reasons. Overall, it was a fantastic learning experience and I loved working with everyone and seeing other people's creations.
I also uploaded the game to Newgrounds, which is a great feeling. I've used Newgrounds to play online games since I was a kid, and I know young me would be super happy to hear he eventually managed to get something he made up there.
I've had a personal website for a few years now and I've been using a static site that's been manually maintained and curated, which hasn't been ideal as I've had to spend an equal amount of time in boring upkeep as I did actually producing content. So, I'm rather pleased to have recently found makesite.py - an elegant, lightweight, and friendly little tool to generate static websites.
The primary design philoshopy behind makesite.py is its simplicity. The entire engine behind it is a single 250 line Python file which is easy for the even beginner programmers to understand. This engine uses templates you've made and combines them dynamically with content and data you've written, compiling it into a static website ready to be hosted. Running the code takes less than a second so the results are immediate, and so it fits nicely into my current workflow using VS Code.
Before now, I was manually maintaining the website's headers, page meta tags, RSS feed, etc. Now, I barely even have to think about that stuff and I'm more freed to write content without managing quite so much of the chores.
There are of course other static site generators out there: Jekyll, Pelican, and Hugo to name a few. But I think most struggle to come close to the simplicity of makesite.py. I recommend makesite.py to anyone who's looking for a static site generator that is as simple as possible or anyone willing to dig a little into the code to really get a bespoke solution.
]]>A common idea seems to be putting a file after the domain root, though there is very little consensus on what this file should be called. Whilst
feed.xml
is certainly popular, I've seen atom.xml
, posts.xml
,
feed.atom
and rss.xml
.[1] Additionally, websites which have blogs
located in a subfolder of the site, such as, commonly, /w
or /writing
will generally, though not
always, have the feed be in that folder and not in the site index.
Looking at the big corporations. WordPress blogs can find their RSS feeds at /feed
, which is a technique a fair few personal
blogs employ as well[2] and this is the system other blogger platforms use, such as dev.to. Meanwhile, Reddit has feeds all
over the place - every user, subreddit, or post has a feed associated with it which you can find by adding /.rss
to the URL.
Its impossible to list all the possible varieties, and I've only just scatched the surface. I highly recommend you read through the responses to this hacker news post, where hundreds of people have shared their blogs, to find yet more interesting instances of RSS implementation.
It's very apparent that there is no standardisation as to where and how you should place your RSS feed in your site structure, which is an issue that might
potentially cause confusion for visitors to your website. The solution I've used for this website is to place redirects everywhere a potential user might
look for an RSS feed. These redirects point to a single atom.xml
file. Below is the gulp task which does this.
var rssStrings = [ 'atom', 'feeds', 'feeds.xml', 'feed.xml', 'rss', 'rss.xml' ];
gulp.task('rss', function() {
let tasks = [];
for (let i in rssStrings) {
tasks.push(
gulp.src("dist/feed/**")
.pipe(rename(function(path) {
path.dirname = rssStrings[i];
}))
.pipe(gulp.dest("./dist"))
);
}
return mergeStream(tasks);
});
Where dist/feed/**
points an HTML file which provides a redirect to the atom.xml
which contains the
feed. Potentially, you could also copy the atom file itself, instead of a redirect. But I decided I'd rather ensure that there is only one atom file I need
to worry about. Using this method, access to the RSS file is as available as possible.
As an aside, I also saw one instance (paul.copplest.one) where the RSS feed was a link to the GitHub commits feed, which I suppose is innovative in its own sort of way.
]]>Changes I made include: allowing the editing of notes; adding a timestamp to each individual notes which shows when the note was last edited; adding a title to each note which is the first line of the note or the first 20 characters, which is displayed in the notes list; adding the ability to delete notes; and restyling the app so its a bit more user friendly. There's still a few more things I want to do, like adding the ability to switch to a night theme and adding persistent storage, but I'm happy with the progress I've made and I'll try getting it to the app store soon.
Through this project, I hoped to get a better grip with C# and dive into the Xamarin toolset, and I'm pleased to say that that was successful.
That is the question asked by Kidney Health Australia at the Hacking for Humanity hackathon organised by Girls In Tech which I tackled alongside four team members. Our solution was a automated chat bot using Google's DialogFlow technology to assess user risk level, combined with a fierce marketing campaign designed to reach as many people as possible whilst being financially efficient.
DialogFlow makes it easy to create a natural language bot for a wide variety of platforms simultaneously, including Facebook, Instagram, and any bespoke location, by planning conversations through the online DialogFlow portal. Data can be extracted from conversations to a cloud instance, as it was in our case to calculate the users risk based on their lifestyle factors. Our demonstration at the end of the 48 hour hackathon included a live bot on Facebook Messenger, who we called Billy the Kidney, as well as a live demonstration on the Kidney Health Australia homepage.
Our solution, though not polished completely on the day, demonstrated the value of the ideas as a cost effective way for Kidney Health Australia to reach and impact as many people as possible.
The weekend also saw other charities and teams present. I was a big fan of Captain Starlight and Heart on my Sleeve, both superb organisations, the former brightens the day of kids in hospitals and the latter reaching out and forming genuine connections with people.
I needed a new website, to replace my old website,[1] for a few different reasons:
I explored a lot of options for design of my personal website - there's a lot of fantastic techy blogs out there to draw inspiration from. My favourites might be this one, this one, and this wonderfully simplistic one. This were all just stumbled into on HackerNews one day. I took the best ideas from all of them and put my own flair into them to create this place.
Currently, the site is written manually with Visual Studio, version controlled with a private Git repository on GitHub, prepared for upload using gulp, then synced with AWS via command line. All written with elbow grease except the svg logos used for the header icons which were taken from iconmonstr.com.
An A4 piece of papercan fit approximately 5000 1s or 0s, or 5 Kb of information, if we use a 10 pt font and sensible margins. That's a disappointingly small amount. But we can greatly improve on this if we don't limit ourselves to having a human readable piece of paper - we can fit much more by reducing the font size to barely readable, printing double sided, and having the most minimal margins. With all these improvesments, we can expect around 50,000 bits on each page (6.25 KB).
It is hopefully quite obvious that this is not a good way of storing written words - language is a much more dense than bits. However, there currently is no future-proof way to ensure our music today is heard as it should be - just recording score in notes and bars doesn't capture the essence of the music as it is heard on record or in mp3s. Is this the best way of recording music for future generations? MP3s are typically 128 Kb/s. Applying that to our bits per paper means a book of 4'300 pages could hold Rick Astley's Never Gonna Give You Up replacing the space taken up by your Song of Ice and Fire collection on your bookshelf. This is worth it.
But we can do better! Instead of inking 1s and 0s on paper, we can instead use hexadecimal to store four times as much information in the same amount of paper, cutting our Rick Astley volume to the mere size of a large book. But there's no reason to limit ourselves to only hex, we have over 100'000 characters in unicode, each of which could represent a series of 1s and 0s, theres no limit to the compression we could achieve, potentially storing megabytes on a single A4! This could then easily be read back in future generations with advanced OCR technology, so long as the key is stored somewhere.
I'm not seriously advocating this. But... maybe...?
The scene consists of a fireworks spawner game object which randomly instantiates firework rockets around itself which move upwards and, after a random amount of time, explode. The firework sparkles explode outwards by the physics collision engine doing its thing since they are all spawned roughly in the same place. Against a backdrop of a night sky, the effect is decent.
Obviously, since everything is a cube, this Unity scene requires a small amount of artisitic license.
The game was my, and I suspect most of my team members', first real experience with C# and the Unity engine and it was fun adding stuff and writing code to fix in-depth issues wherever it was needed. Though, I must confess, how Unity handles control flow and objects is quite confusing and there is no doubt that we did not follow best practices during this 48 hour project. Having said that, it was incredible enjoyable.
This was done by first iterating over every pixel in the image after it has been onverted to greyscale. The luminance of every pixel was then calculated by using a formula found online:
// calc luminance in range 0.0 to 1.0; using SRGB luminance constants
float luminance = (red * 0.2126f + green * 0.7152f + blue * 0.0722f) / 255;
This luminance value was then stored in a very large 2D array. The array is then looped over and certain ASCII characters are chosen based on the luminance value selected.
diffLum
is the difference between the largest value of luminance found (largeLum) and the smallest value of luminance found
(smallLum), the addition of this as opposed to set values between 0 and 1.0 mean that the whole range of characters is still used even if there is not a
great difference in the source image's luminance values.
// choose brightness threshold as appropriate:
if (luminance <= (diffLum*0.1) + smallLum) {
chars[x][y] = ' ';
} else if (luminance <= (diffLum*0.2) + smallLum) {
chars[x][y] = '.';
} else if (luminance <= (diffLum*0.3) + smallLum) {
chars[x][y] = ':';
} else if (luminance <= (diffLum*0.4) + smallLum) {
chars[x][y] = '-';
} else if (luminance <= (diffLum*0.5) + smallLum) {
chars[x][y] = '=';
} else if (luminance <= (diffLum*0.6) + smallLum) {
chars[x][y] = '+';
} else if (luminance <=(diffLum*0.7) + smallLum) {
chars[x][y] = '*';
} else if (luminance <= (diffLum*0.8) + smallLum) {
chars[x][y] = '#';
} else if (luminance <= (diffLum*0.9) + smallLum) {
chars[x][y] = '%';
} else {
chars[x][y] = '@';
}
The chars array is then looped over and written into a text, .txt, file.
The solution works adequately however the output cannot be resized and so the source image must be downsized quite a bit before it is truly useful as an ASCII converter.
]]>It the 48 hours which spanned the jam, I helped develop the basic quests and gods outline and tried to overall polish the game through adding unique mouse cursor, splash/intro screen, win screen, death screen, as well as fixing some issues that were left over from when the game engine was used last year.
The by far simplest method is to save the document as a webpage. This is done by choosing the correct file type when saving as a new file. This is done as normal when saving the file but choosing a different "save as type". Below is a screenshot of saving a document called "Example".
Next, simply navigate to the folder where you saved the document as a webpage and you should find a new folder called "Example_files" alongside the new .htm file. Inside the folder will be every photo within the document in a .jpg format along with some meta data and other stuff you dont need to worry about.
Hooray!