Some of my unity one game a month projects.
This year, I’m taking part in the One Game A Month challenge, in an attempt to build a habit of finishing games. I’m not quite a game making machine yet, but even if some parts are rushed I’ve already produced far more in terms of gameplay than I did in the whole of last year. Having a short, enforced deadline for each game helps avoid the temptation to procrastinate with planning or polishing as an excuse.
So far, I’ve managed to get three playable games done and submitted:
Arc Breaker – A very simple, stylised shmup.
Rain or Shine – A puzzle game, and my first ever HTML5 / canvas project.
I so rarely manage to get a finished product out of game ideas these days, most of the things I’ve been making are actually fan art. When I really fall in love with a game or story, making something to do with it is a nice way of lingering a bit longer in the playground. I’ve added a small set of galleries to post this sort of thing, starting with some panoramas from Gravity Rush:
and a pair of wallpapers for Analogue: A Hate Story:
Rorrim is a little puzzle platformer I put together over the weekend. I made it partly just so I had something playable I could use to work on the platforming code for different project. But I thought it was quite fun in its own right, so I cleaned it up a bit and made it into more of a proper game.
It only has six levels at the moment, but there’s an extra challenge once you’ve completed it if you find them too easy.
I’d like it if my browser history was ordered by when I closed a page rather than when I opened it.
More precisely: The history would work as usual, with pages added at the top as they’re opened, but when a page is closed it gets bumped to the top of the list.
Most of the time your history would work as before. For example, if you browse extremely simply — opening a single page, reading it, then closing it — this new rule would make no difference. However, I think this new behaviour would match a lot more closely with my mental history, and there are at least a few situations I encounter regularly where I would find it helpful:
Accidentally closing a window.
With a regular history, the page(s) you closed could be anywhere in the list. Most browsers have an Undo Last Closed Tab / Window command now, but in Safari at least this only appears to go back a single step. With a changing history, you’d find your pages right at the top.
Following links from a large article.
When I have an article, gallery or other “hub” page open, I’ll usually briefly visit linked pages, then return to continue reading the main page. If I wanted to find the article again after closing it, a regular history would require me to scroll past all of the sub-pages I opened, looking for their start point. As the main page is normally closed last, it gets popped to the top of the list and acts as a header for the associated pages while leaving them in the order you would expect from a normal history.
Leaving a page open to read later.
Often, I will read pages in a very different order from how I opened them. This means that the order in which I remember interacting with each page is disconnected from their order in my history. Ideally, my actions and the browser history would match up perfectly, but until computers can read minds, the time the page was closed serves as a good approximation of when I last focused on it. Now, instead of searching for the effectively arbitrary position in history of something I left in the background for a few hours, I just have to remember when I actually read it.
Is there a browser (or browser extension) that does this already? I haven’t been able to find any way to do it in Safari or Firefox yet.
I got a little stuck on a project this weekend, so for a change of pace I decided to remake an old puzzle game experiment and polish it up a bit.
Drag the small bars at the bottom to try and make the two graphs match up.
For more (or less) of a challenge, you can change the number of blocks using the boxes along the top. One or two blocks is obviously trivial, but it can get very challenging from six upwards.
The patterns the blocks make reminded me of paper chromatography experiments we did back at school, and my brother suggested they were a bit like X-rays, which apparently were once called “skiagraphs“. “Skia” comes from the Ancient Greek for “shadow”, which seemed appropriate, and in any case it sounds a lot better than “Block Puzzle”.
I wanted the interface to look like an LCD screen, so I’ve experimented with adding a couple of slightly unnecessary full screen effects. They eat quite a lot of CPU, so you can turn them off in the context menu if you prefer.
I fell for a password phishing email once. The moment I clicked the login button I thought “Wow, I’m so trained to do this all you have to do is show me the button and I’ll click it.” I realised a split second later of course, and felt like an raging moron for not paying attention.
The thing is, why should you have to pay attention? Even if you’re not quite as dim as me, it still takes a little bit of mental effort to tell a well made fake email from the real thing, and it’s a lot harder if you’re not tech savvy enough (or too groggy from just waking up) to spot the warning signs. I think there’s a very simple addition to normal security measures that would make recognising fake emails and account pages universally effortless, while requiring no extra input from the average user.
When a new user signs up, they’re presented with a randomly chosen “security colour”. They can pick a different one if they prefer, and from then on the colour is displayed as a banner or badge on every official communication from the site.
The colour would be kept secret, like your password, so any potential phishers would have to guess at what colour to use. The actual way the colour is displayed could be styled a little to match the site, but as long as it’s used prominently and consistently enough to become part of the expected branding, an off-colour message would appear as obvious as one with the wrong logo or name.
We were going to just throw this broken bowl away, but I wanted to see if it could be glued back together, wrong.
Entanglement is a board game idea I came up with a couple of months ago, with a Flash implementation that lets you play with another person locally or against the computer. I think the seed for it came from a dream I had one night, although all I managed to actually recall of it in the morning was “Mancala on a chessboard“.
Mancala is a very old family of board games whose basic move involves taking a pile of pieces, then placing them one at a time in a row as if you were sowing seeds. In the version of the game that I know best, the board is made up of two parallel rows of depressions — one row belonging to each player — along with large spaces for each player at the ends. You move around the board in a loop, always in the same direction. If the last piece in your move lands in an empty space on your side, you capture all of your opponent’s pieces in the dip opposite. There are only one or two special rules beyond this, making it a very simple and satisfying game.
I took the counters from a little travel Connect Four set and started experimenting with transferring this movement to a grid. At first I tried allowing movement in any direction, but this quickly became confusing, with chains overlapping and squares containing piles of both colours. Restricting movement to squares of your own colour meant that you could now only move diagonally, and kept the two sides permanently separated.
Mancala style capturing didn’t make much sense on a checkerboard, so I tried out a rule inspired by Go (or by my simple understanding of it), capturing your opponent’s pieces by surrounding them with your own. However, with the pieces restrained to their own squares, it’s not possible to simply surround a group of squares without there being an empty square of your own colour inside. Disallowing this reduced the possible capturing formations down to diamonds made of four squares around a single square, or partial diamonds against the edges of the board.
To resolve situations where diamonds overlap and multiple squares are surrounded, whichever diamond has the most pieces captures first, and diamonds with equal populations capture simultaneously. This means you can safely capture a square that is part of a diamond as long as you build a stronger diamond, and it’s possible to sacrifice a piece to break a diamond if you can only match strengths.
Finally, the layout of the board — which squares have pieces on and which don’t, ignoring the actual number of pieces on each square — must change with each move. This is probably the least clear of the rules, but it’s the most elegant way I’ve been able to come up with to help avoid easy stalemates.
These rules (which are listed in the Flash game as well) seem to allow for a lot of strategy and interesting situations. I haven’t had a chance to really test the game with anyone apart from my brother though, so any suggestions or improvements would be very helpful.
Play a work in progress version of the game here.
(The computer opponent is still a little buggy, and can become extremely slow if you build large towers. If you run into problems, the easy difficulty level is much faster, if a bit less smart.)