As some of you may have noticed, the company that makes Candy Crush Saga (King) have trademarked the word Candy and are demanding that games using the word be removed from the app store. This is a rather disgusting move and as a result a number of indie developers have decided to produce games using the word Candy. Hopefully this will help spam King’s lawyers leaving them to sift through a sea of games with the word Candy in the title and they will eventually drop this ridiculous idea.
So, here’s my game, Candy Crush Aga! In which you use an Aga (it’s a kind of cooker thing which people seem keen on but is actually quite hard to cook stuff with) to crush candy as it comes along a conveyor belt.
When we were first making Gateways the graphics weren’t in an 8-bit style, they were higher definition. While we liked the graphics it seemed like they were missing something. After a suggestion from the author of ASCII Portal we tried reducing the graphics to a more 8 bit style and ended up with the graphics that are currently in the game.
Due to the way the graphics were scaled down from a higher resolution version they did end up looking a little on the blurry side. Some key graphics were completely changed to be more true to the 8-bit style like Ed and the enemies. Other graphics were touched up slightly to seem less on the blurry side but it’s always been one of those things it would have been nice to completely redo. We’re now finally finding the time to go back over a lot of the graphics like the backgrounds and make them much more like what we would have wanted had we started out using an 8-bit art style.
We’re aiming to have a new version out in January which will have the updated graphics. Here’s a few comparison screenshots to whet your appetite. You might need to click ‘em big to really see the differences:
A post appeared on the Gateways forums recently with a video showing,… a bug, or a kind of a bug. Here it is:
It raises some interesting questions and took me back to handling the time travel stuff so I thought I’d write a blog post about it.
If you’ve played Gateways and got as far as the time travel guns then hopefully it’s obvious what’s going on here. If you’ve not then you probably don’t have a clue what’s going on so I should explain a bit how the time travel gateways work. The first gateway that’s placed (on the wall to the left) is the ‘return’ gateway. When the second gateways is placed (on the floor) it connects up to this first one at the time it was placed. Travelling through the second gateway takes you back in time. The first gateways is placed at 0:04 and the second one at 0:10 so travelling through takes you back in time by about 6 seconds.
The switch in this level has been wired up to close the door rather than open it. This means that before travelling back in time Ed can walk back and forth through the door. By travelling back in time and standing on the switch the door closes and it appears that Ed is walking back and forth through a closed door. You can see how it can happen but it looks like a bug. The question is, how would you fix something like that? The previous echo of Ed has already been recorded, should that be changed?
The initial time travel game I wrote back in 1999, TimeSlip, first made me think about this issue. In order to implement time travel you have to record the previous actions of the player so they can appear as past echoes when they travel back in time. My first instinct was to implement this by recording the player’s key presses and playing them back to make the past echoes recreate the previous actions. Here’s an example of what can happen when that’s the case:
There’s a single door here and the switch on the left will open it when stood on. In TimeSlip you travelled back in time automatically so there are no gateways to travel through.
The player walks into the door and hold down the right key. The door is in the way so stops the player moving.
The player walks back and stands on the switch which opens the door.
The timeslip happens and the player travels back to encounter his past self. He becomes the snail numbered 2 and the first echo is number 1. This echo walks to the door but is now able to walk through it putting him in a different place to what actually happened first time round.
The past echo (1) now walks back but only walks as far as he did the first time when he was blocked by the door. This means he doesn’t end on the switch. The current snail steps off the switch, making the door close.
We travel back in time again so past echo 1 reappears. The snail that used to be numbered 1 becomes 2 and the one that used to be 2 becomes 3. This time round the first past echo reverts back to what happened originally because the door is closed. It walks up to the door and is blocked by it.
Now the first past echo walks back and stands on the switch, exactly what happened the first time round. When we travel back in time again the switch will be pressed and the door will be open so the first echo will go through the door again, just like the second time round the loop. We end up in a weird state of alternating between two different versions of events on each timeslip.
While this initially seems quite fun the end result is something that’s incredibly confusing for the player, and time travel is confusing enough as it is! Past echoes end up jumping around randomly and eventually land on spikes or cause paradoxes between other past echoes. All this can happen off screen so the player often has no idea why they just lost the level. The whole system doesn’t work.
What actually happens in any game involving time travel I’ve made is that the actual positions of the player are recorded rather than the key presses. This ensures that they always take exactly the same action so the player can rely on their past echoes doing what they did the previous time.
It still leaves the problems like the one shown in the video, so how are we supposed to get round that? It basically boils down to the classic Grandfather paradox,where a time traveller goes back in time to kill their grandfather. If they kill their grandfather they will never be born and never travel back in time to kill their grandfather. If they don’t kill their grandfather then they will born so they’ll travel back in time and kill their grandfather. It’s a paradox.
One method that’s used in TV and movies to get round this paradox is the idea that travelling back in time takes the protagonist to an alternate version of reality. If they kill their grandfather in the alternate reality then that’s fine, they won’t go on to be born in this version of reality and they can change the past as they see fit. This sucks from a gameplay point of view though, you need your past echoes to perform the same actions as before and the past to remain the same.
Of course I used interacting with yourself in TimeSlip, Shuggy and Gateways as the cause of a paradox which generally meant you had to restart the level. I could have done the same thing for the type of situation shown in the video. I could have recorded the key presses and the positions. If, during the course of replaying the key presses the echo ended up in a different place to the recorded position that would cause a paradox. In Gateways that would mean the screen would go all wobbly and the time travel effect would end as soon as the player started to move through the door. I decided I didn’t like the idea of this method as it’s too easy to cause a paradox in this way and it can often happen off screen leaving the player wondering what went wrong.
The answer I decided to go with follows the Novikov self-consistency principle which states that a time traveller simply can’t make changes that would lead to a paradox. There would be no way for them to prevent their own time travel event. If they were trying to shoot their own grandfather then the gun would jam, if they tried to run them over they would have a car crash before reaching them. This is implemented in Gateways (or it should have been :/) by preventing the switch from working that would close the door. The door would remain open until Ed was finished dancing around underneath it; at which point it would mysteriously start working again.
Here’s a couple of examples of where it does actually work in the game:
Here the switch has been wired up to make the platform move. By standing on the platform before travelling back in time we have to make sure that the platform is in that position for Ed to stand on it. Hence the switch fails when it’s stood on after travelling back in time. As soon as the player’s past echo stands off the platform the switch becomes active and the platform moves again.
In this example a laser is being redirected to activate a switch that opens a door. We then try and prevent this from happening by deflecting the laser away. The mirror mysteriously fails to reflect the laser because that would prevent the door from opening. Note, at the times when the laser isn’t hitting the switch the mirror functions again and the laser can be redirected.
Implementing this stuff did prove rather tricky and I suspect I never implemented the case with the door because there weren’t any doors like that in the original game. I suspect most people that played the game didn’t even realise these cases could arise and were handled so in many ways I’m glad someone has raised this! With the release of the editor people will probably find more weird cases like this,… can you think of some?
Oh, and my next game won’t involve time travel. Too much of a headache!
When I saw Ludum Dare coming up I wasn’t sure if I’d take part or not but when the theme was announced (10 seconds) I knew immediately what game I wanted to make which is quite rare for a game jam. I’d been playing Pikmin 3 recently and wondered why there wasn’t a similar game on the PC (perhaps there is, I haven’t look that hard to be honest). Each level would be a single screen with a time limit of 10 seconds but you could pause the game and decide who you were sending where before letting it run again, a bit like FTL. Each level would have a target object that you had to carry back to your base but collecting the other tokens dotted around would be key to increasing the number of little peeps you have as they carried over to the next level.
I knew the path finding was going to be the difficult bit to get right so I decided to tackle that first. I decided to use a node based system where the map was made up of several interconnected nodes and the peeps would move from node to node. Here’s a picture showing the nodes from one of the levels:
The red nodes are the ones that are explicitly specified in the code for the level. The white nodes are created when I specify that two red nodes are connected. There’s a function that splits the connection into smaller chunks, automatically creates nodes in a line and connects them all together. There’s another function for creating a circular shape, the white nodes around the edge of the circle are created automatically based on the centre node. Doing all this meant the code for this level only contained 17 lines specifying the key nodes. This system help me create 5 levels for the final game.
One terrible decision I made was that the peeps should be stored in groups. They would initially start all in the same group but if the player shift-clicked to move some peeps a new group would be created. Only one group could be selected a time so selecting one group and shift-clicking on another would merge the two together. I had problems when some members of a group collected one of the tokens because they would head back to the base, splitting the group in 2. I had to code a special case for this which was really fiddly. I then realised that a lot of peeps would all end up back at the base but all be in separately selectable groups. The player would have to merge them all together manually, it clearly wasn’t working.
I realised the group idea wasn’t going to work so I had to make quite a few changes and introduce the click-drag method of selecting peeps (before you would just click on the group). A lot of code ended up getting taken out which is normally a sign that you’re doing things the right way. I feel pretty confident that the system I ended up with is much better.
The barriers and enemies were added next. They are associated with one of the key nodes and never move. Adding them was relatively simple, I just had to update the path finding code so that peeps could move into the same node as them but couldn’t move past them. If I detect a peep is trying to move into an enemy or a barrier they don’t move but attack instead. Each enemy and barrier has a health count that decreases as it’s being attacked and disappears when it reaches zero.
The tokens were a bit more tricky because they have to be carried by the peeps. As a peep reaches a token they tell it that they’re trying to lift it and the token keeps a count of how many peeps are lifting. Once that counter reaches the appropriate amount the peeps are told they can move it and all start heading back to the base. At this point the token’s position becomes the average position of all the peeps carrying it.
Towards the end I focused more on adding levels and testing the game. I found the game to be really quite enjoyable to play and I’m really happy with it. My aim in designing the levels was that it should be possible to collect all tokens but not necessary. It’s always hard to pitch the difficulty of your own game but hopefully I’ve not made it too tricky. Why not give it a try and see what you think:
I had booked my ticket for London GameCraft almost as soon as it was announced, I do enjoy a good game jam. To my surprise as the date for the event approached I was actually invited to be a judge. I’ve never been a judge for a game jam before but I thought it sounded like great fun and agreed. And then it dawned on me; if I was a judge I wouldn’t be able to take part! In the end I decided not to let being a judge stand in my way and tinkered away on my own little project in between checking out the real entries and walking around with tinfoil on my shoes,… don’t ask.
There were some really impressive entries and we had winners in a few different categories. The theme was “The Impact of Prism”, presumably referring to the NSA data gathering program. It led to a split in the entries with some people going with the data collecting thing and other people going with the light refracting type of prisms. Other jammers have blogged about their day here and here.
I ended up being quite fond of the little game I produced that day so yesterday I polished it up a bit and have stuck it on the website for your playing pleasure. It’s called “Get Off My Data”:
You can download it for PC here. You’ll need XNA 4.0 installed.
It’s a twin stick shooter, tower dense type of game. You can use keyboard/mouse or an Xbox pad. You must defend your datas from the NSA by shooting them and placing defensive turrets. Collect tokens dropped by the NSA mobs to upgrade your turrets, weapons and movement speed. If you have enough tokens to buy something then the item will flash.
If an NSA agent collects your data you can still shoot them before they leave the screen to get it back. Move over data to pick it up and return it to the centre of the screen. If all your datas are taken then it’s game over. Get hit by too many NSA agents and lose all your lives then it’s game over.
By now everyone has the 16th of July pencilled in their diary for the release of Gateways on Linux and Mac. Eventually all deadlines for video game releases have to move though. Can you believe we’ve actually decided to move the Gateways release forward? As of tomorrow (the 9th of July) Gateways will be available for Linux and Mac through the Smudged Cat website and Steam. Ultimately it makes perfect sense for a game about time travel to have its release date moved forward. Since I’m so generous there will also be a 50% discount. Even more good news!
Opening the game up to other platforms will be interesting for me. Fifteen thousand people or so have played the game now so it will be fun to see how much that figure changes with the launch of these new versions.
Since the beta release of the Gateways editor about a week ago it’s been interesting to see a few home brew levels appearing. To be honest I’d love to see even more. Eventually I’ll get support for Steam Workshop in there which will hopefully inspire more people to test it out. As work progresses on the editor I’ll keep you posted about any exciting new features. My own new map designed using the editor should be available very soon!
So that’s all for now. As always you can follow me on Twitter or like the Facebook page to hear about any new announcements. Look out for Gateways for Mac and Linux tomorrow. Email if you have any problems!
I decided a while ago it would be nice to release an editor for Gateways. Obviously I had an editor that I used to make the game itself so I decided it wouldn’t take too much effort to neaten things up and release it to the world. Naturally there was a bit more work involved than I first thought as tends to happen with these things but I’ve now released a beta version of the editor.
A new version of Gateways (1.12) went live yesterday which includes the ability to load user generated levels. If you’re on Steam or Desura you should get notified about the updates. If you bought the game through the Humble Widget on the website then you can download the latest version using the link you received when purchasing.
There were a few more changes included in the latest version like the ability to redefine the keys from within the game, ambient light and light from the torch passing through gateways, the next objective arrow and post processing effects can now be disabled from the menu and there is a start screen in the PC version so you can start the game from any controller.
I’ll still be actively working on it so I appreciate any feedback about the editor. I’d like to integrate support for Steam Workshop but I haven’t fully looked into the details about that yet.
I uploaded a demonstration video that shows some of the features of the editor:
If you create something worth sharing then I recommend posting about it on the Gateways forums.
I received a curious email this afternoon from the XNA Team. It was the automated email you receive when an Xbox Live Indie Game has passed peer review. It told me that Gateways had passed peer review. This left me feeling a bit puzzled because I didn’t have Gateways in review at the time. I decided it was a weird glitch and didn’t think more about it.
However, I got a tweet from the good folks over at CSR Studios telling me that Gateways was back at the top of new releases. I fired up the Xbox and had a look, and sure enough there it was as a new release. It then suddenly dawned on me what had happened, there were two copies of the game on the system, ‘Gateways’ and ‘Gateways’!.
I was ready to release Gateways about this time last year, it had passed peer review and I was getting ready to push the button to make it appear on XBLIG. Then the guys from the Indie Uprising got in contact with me and asked if I’d be interested in joining them for the next uprising. I thought that sounded like a great idea (and it was) so I held off releasing the game.
As I waited for the uprising to kick off I started making a few changes to the game. A few tweaks here and there and a few bug fixes. Obviously I wanted to get these new changes into the release but there didn’t seem to be any way to do this if the game hadn’t been released on the system. The only option I had for ‘Gateways’ was to release the game.
It seemed the only solution was to create a new project called ‘Gateways!’ and use that. I would simply write off the ‘Gateways’ project (there didn’t seem to be a way to delete the project) and never release it. It would seem that today Microsoft have made that decision for me and it got released. I can only presume there is a time out of a year on all projects that have passed peer review.
I’m not sure what to do now. Like many XBLIG titles, Gateways (or rather, Gateways!) hasn’t performed well for me. My App Hub membership ran out in May so I’m now unable to get in and make changes to any projects. I’m not planning on releasing any more XBLIG titles so I’m reluctant to fork out the money to rectify this problem.
The Mac and Linux ports of Gateways have been going well and I’ve now pinned down a launch date of the 16th of July for them both. They’ll cost $5, the same as the PC version, but I might be tempted to have a little sale at the time of launch.
I’m interested to see how the Mac and Linux communities respond to Gateways because I’ve never released a game on either platform before. Hopefully it’ll be embraced in the same way it was on the PC and a whole new raft of people will get to enjoy the game. If there’s a good response to the game then ports of Adventures of Shuggy will likely be on the cards.
If you’ve never heard of Gateways before then you should a) be ashamed of yourself and b) have a look at the trailer and checkout the website.
Meanwhile, I’ve been continuing work on the Gateways Editor which I’m feeling really pleased with now. I’ve worked out all the kinks that I had put up with while I was designing the game itself so it’s a lot more user friendly than it used to be. I’ll be releasing an update of Gateways later on in the month with the ability to load user generated maps and a beta release of the editor at the same time. I need to look in to adding Steam Workshop support, I’ll create a thread on the forums where people can share maps for the beta release.