Sean's Tech and Writing Blog
30 July 2014
The team behind the Scratch programming language has released ScratchJr for the iPad, following a successful Kickstarter campaign which I was pleased to support with a small donation. ScratchJr is aimed at younger children, aged 5 to 7 years old, and has a simplified interface and set of blocks for making scripts. It has some great looking graphics, and the blocks can be used to create some surprisingly sophisticated effects. The app can be used to make stories with different scenes (a new feature in ScratchJr), and simple games too.
Our nieces and nephews are already experienced iPad users, so I'm confident that the interface will present no challenge at all to young children. They quickly learn what the icons mean and happily explore what they do.
Here are three scripts you can use to make an arcade game in ScratchJr:
To understand how that program works, and get an overview of the new app, see my review of ScratchJr on the iPad, including how to make an arcade game. If you're a fan of ScratchJr's older cousin Scratch, check out the bonus resources from my book Scratch Programming in Easy Steps.
28 July 2014
At this month's Londroid Meetup at Skills Matter, there was a chance for developers to learn more about how to create successful apps for Google Glass. It presented an opportunity to see the devices, but most importantly, a chance to hear from Google representatives about what Google has learned about making Glass apps through trial and error. Senior developer advocates Hoi Lam and Timothy Jordan gave talks, sharing their favourite apps and best practice using Google Glass.
Here are the key takeaways I noted:
- Know your techs. There are three ways you can develop Glass apps. You will be able to use the upcoming Android Wear notifications, which will push notifications from your Android phone to your Google Glass. You can use the Google Mirror API if you have a web service to deliver that into Google Glass with minimal changes. Or you can use the Google GDK (Glass Development Kit), which adds some Glass-specific features to Android, including voice triggers and gestures. The Mirror API can enable you to implement your app more quickly, but it means output is pulled from the cloud. It's best used when it will feel intuitive to the user if there is a delay in getting information, such as in a searching application. The GDK is suitable when you need an app to work offline, need a real-time response, or need deeper hardware integration.
- Design around user intent. Although I'm talking about applications here, Glassware, as they call it, isn't like a phone or a tablet app. Users won't expect to open an app and then do something. Instead, you should design around their intent and cut the time from their expression of that to you delivering a result. For example, a tablet user might open a mapping app and then search for directions. A Google Glass user would just ask for directions.
- Design for Glass. App developers are experienced at porting from "one rectangle to another", but Google Glass isn't just a smaller rectangle. It's so different to existing mobile platforms, that you need to rethink the experience you provide. Jordan suggested thinking about what it is you always wanted to do with your services that you can now do with Google Glass, and then focus on that one feature. Wordlens, for example, provides hands-free translation of signs using the camera, leaving your hands free for maps and baggage. Augmedix enables doctors to look up medical information without turning away from the patient, and enables them to build stronger rapport and better study the patient's condition.
- Don't get in the way. Google's vision for Glass is that it should not interrupt the user and take them out of the moment. Lam had a great example of how he's been using Google Glass to photograph his daughter while playing with her. He can look at her all the time and use both hands to guide her on the climbing frame, but can capture that moment using Google Glass. Google's aim is that the device should enhance living in the moment, rather than pulling people out of it. As a result, users should be able to ignore your Glassware without any penalty, and it shouldn't require them to take action.
- Be relevant. Google Glass isn't designed to provide all the information, all the time, just what's most relevant now. Think about how you can use contexts like the time of day and the location to provide relevant information to the user when they need it. For example, it would be great if a shopping list app presented a reminder just as you're passing the shop, Jordan suggested. Because of the need to focus on what's relevant now, you can't just port your mobile apps across and expect to end up with something usable.
- Avoid the unexpected. One of Google's guidelines is that you shouldn't surprise the user in a way they don't want. This probably applies to every platform, but it's especially important for Glass, because the nature of the device means that unpleasant surprises would feel particularly intrusive. Nobody wants to see cabbage adverts in their glasses at 3.30am. Jordan presented CNN as a good example of managing expectations. When the software is configured, it makes it clear to the user how many alerts they will see and when they're likely to see them.
- Build for users. Jordan said that Google had tried building some applications that didn't work, and advised against building something just because it seems cool and takes advantage of the technology. Instead, you should focus on a problem that people have and help them to solve it. Again, this might seem like something that applies to every platform, but it's still a good filter to put your idea through before developing it. The idea of a facial recognition app came up that would tell you who somebody was when you met them again, having forgotten their name from your previous encounter. That seems like a cool idea, but it would get in the way of the real social interaction. In practice, I think it would be pretty hard to use without somebody knowing it was being used on them, which would be a particularly graceless way to socialise. (Facial recognition apps are currently not allowed on Google Glass in any case).
- Be wary of head gestures. They can be a cool way to control Google Glass, but people lack fine motor movements, so they're not good where precision is required, including in scrolling.
- Make it glanceable. Jordan presented two different designs of a running app, both of which showed the steps taken and the percentage of the run completed. One of the pics had a photographic backdrop showing some running shoes. When the room was polled on which design they preferred, it was evenly split. The screen with the shoes in, though, took longer to glance at, eye-tracking studies had shown. The eye is distracted by irrelevant information and graphics, and when you're running, you can't take in information as quickly. Keep the design simple, and think about what the user really needs. During the run, they need coaching support, not a complete data set.
- Expect design delay. Plan to spend time iterating on the user experience. Until you've tried it, you won't know what works effectively, so allocate plenty of time to experiment with this new interface.
It's early days for Google Glass, and there was a lot of excitement in the room just seeing the devices and trying them out. There's clearly a lot of potential for innovative new applications, particularly for platform-based services, which will be better able to build a business model on a device that is not conducive to advertising, and that does not yet support monetisation. What are your thoughts on Google Glass?
03 July 2014
When I discovered Scratch, I was fascinated to see that the language enables you to put scripts on different sprites, or multiple scripts on the same sprite, that appear to execute at the same time. This is a bit like threading, an advanced programming technique that enables you (in very basic terms) to have different bits of a program executing in parallel (at the same time).
There is a special class of bug that emerges when you're dealing with parallel code, which is the race condition. This happens when two different bits of the program "race" to do something at the same time, and the programmer doesn't have control over which "wins".
For example, if I put all these scripts on the same sprite, what is the final value of the score variable?
It doesn't matter what your guess is, because there's no sure way of knowing how it will behave next time. It might change depending on what else is going on in the program, or a minor update to Scratch might change the synchronisation too. Logically, it's not something you can control. If you ask the program to do four things at the same time that don't make sense together, you risk getting unexpected results.
From my own quick and dirty experiments, it looks like the one that runs last (and ultimately sets the score) is the one you edit or move last. So if you, in the editor, drag the set score to 0 block and then click the green flag, the final value of score is 0. To get the value 8, drag the blocks in this order: set score to 0, set score to 5, change score by 2, change score by 1, and then click the green flag. I put all these scripts on the same sprite. When you have more than one sprite with conflicting scripts on it like this, sprites that were added to the program first have higher priority over the final result. So the cat seems to trump other sprites, for example. I ran my test in Scratch 2.0, but the results are different in Scratch 1.4, and might even be different for you running Scratch 2.0. And they might be different tomorrow for either of us. There's no reason why they have to stay the same.
That's a bit of a diversion because this information isn't really useful to you: for the program to make sense to others (an important part of programming), and to always run reliably (even if someone else moves a script), you need to avoid race conditions like this, not work around them.
It might seem like this is a bit of an artificial example (okay, it is), but similar problems can often occur when lots of scripts start when the green flag is clicked, or the background changes, or when there is a particular broadcast. There have been a couple of times I've experienced problems similar to this, including when writing Hangman for my book Scratch Programming in Easy Steps and the Shaun the Sheep Football game more recently.
There are a few strategies you can use to avoid race conditions:
- Avoid having more 'green flag' or other hat scripts (with rounded tops) than you need. If you can combine them without causing any problems, it's best to do that. That enables you to determine the order the blocks run in.
- If you have a bug that might be caused by a race condition, try adding wait blocks to delay some of your scripts so they execute in an order you can influence. This is a real fudge so I wouldn't recommend it for final programs, but it can be valuable for finding bugs when you're testing your program.
- Use Scratch broadcasts to synchronise between sprites where necessary. For example, you could have a green flag script that sets up your variables and gets everything else ready, and then sends a broadcast to start scripts on other sprites. That avoids a clash where the other sprites might be trying to use variables you haven't set up yet (for example).
- Use the broadcast and wait block where it makes sense. That stops your script steaming ahead before getting the results it needs from other scripts that it's triggering.
Have you experienced bugs like this? How did you overcome them? Let me know in the comments below.
30 June 2014
At the weekend, I visited Google's showcase for Google Glass in London, following the recent announcement that Glass was going on sale in the UK for the first time. I was concerned that there would be huge queues and little opportunity to try the devices, but we experienced no significant wait and had plenty of opportunities to try what we wanted to on the devices. The event had a relaxed feel to it, and we had lots of opportunities to ask questions of people who had been using the devices for a while, as well as to get a feel for how they work ourselves.
22 June 2014
I blogged last week about the fantastic Shaun the Sheep character and prop sprites that Aardman has made available for Scratch games, and how you can extract them to use them in your own games. I've now published my own Scratch game using them, Shaun the Sheep Football (also embedded at the end of this blog post).
Once I'd decided I wanted to use the sprites to make a project, I had a think about the kind of game I wanted to make, and came up with these guidelines:
- I wanted to create a repeatable game mechanic rather than creating a game with lots of level designs. I thought that would present a more interesting challenge for me, and enable me to focus my attention on the code rather than the level design.
- I wanted to use the characters, rather than just the sprites. Perhaps I was overthinking this, but I thought it would be good if the sheep and pigs could interact in a way that wasn't too artificial or too 'video gamey'. I wanted to use a scenario that felt like it could come from an episode of the cartoon.
- Using the characters rather than just the sprites meant that I had one Shaun the Sheep, Shirley suspended from a wire, and two other sheep characters I could use. The pigs all look the same, so I could use an unlimited number of them.
- Shaun had to be the star of the game, obviously.
A football game, pitting Shaun against the pigs with an automated sheep goalkeeper, met all these requirements, and enabled me to try several things I hadn't tried before. One was creating a flick-screen game, because the pitch stretches over five screens placed side by side horizontally. The sprites move all the time, but have a script that loops continuously to show them if they're on the same screen as Shaun, and hide them if not. Keeping the sprites moving, even when Shaun isn't looking, made the game feel more authentic. It's particularly good that the pigs can keep moving towards the goal and shoot even if Shaun doesn't follow them, so there's a feeling that they are playing the game too, rather than just being there for Shaun's entertainment.
I used the animations at appropriate points in the game to try to make the sprites seem more character-like. Shaun's running animation is superb and adds a lot, but I also used some of the other sprite animations to flesh out the game. Shirley (the referee) drops in on her wire to announce the outcome whenever there is a shot at goal. (Bearing in mind that Shaun might not be watching when the pigs shoot at the goal, it was important to provide feedback on what they're doing). The sheep goalkeeper sprite stretches out its arms when it's diving for the ball, and claps its hand to its forehead when it lets a goal in. The jumping sequence that was created for platform games is used for a victory dance when Shaun scores a goal. The goalkeepers "dive" to a random point in the goal when a sprite shoots at them. I also put in the walking sheep as a non-playing character. He just wanders around the screen, but makes the pitch feel more full and makes it feel less like Shaun vs The World. (The walking sheep is the only one that doesn't move all the time, as a speed optimisation).
The game mechanic was quite complex to work out, especially the pigs. I started off by creating a pig that homes in on the ball and then runs towards the goal when he gets it, and shoots. The other pigs move around without regard to the ball, but if they touch it, they also run to the goal and shoot. That makes them more like obstacles for Shaun to dribble around, while the homing pig will actually chase him for the ball. Shaun can tackle any of the pigs to take the ball back, and they can tackle him too. When a pig shoots (by reaching a point close enough to the goal) or Shaun shoots (when the player taps Space, any time on the pig goal screen), the ball moves at a randomly chosen angle towards the goal. Although there's an element of chance in there, you can increase the likelihood of scoring by getting close to the goal and being close to the middle of it when you shoot. If the defending pigs don't get in the way!
To provide a visual hint that the screen flicks, and also to help people understand where the ball is when the pigs have possession, I added a graphic at the top of the screen that shows the ball's position on the pitch.
I set a time limit of two minutes. That feels like a good length of time for a match, and enables the pigs and sheep to each score a few goals. I didn't want to have a game where the scores could get unrealistically high for a football game. In some games, there is a mechanic like energy or lives to dictate the end, but the only natural way to end a football game is when the ref blows the whistle. It was important the game didn't go on forever, otherwise there would be no real sense of winning or losing, and people would just stop playing unfulfilled at some point.
I tried a few things that didn't quite work, and took them out again. One was enabling Shaun to kick the ball away from him (or shoot) at any time. Although it added authenticity, it also added complexity and didn't really enhance the gameplay. I tried using a grass texture for the pitch, but it made the characters harder to see (the Shaun sprite is quite fine in detail, with a white body and black legs). It looked better with a plain background that offers a good level of contrast with both white and black.
I experimented with the relative speeds of Shaun and the pigs to get them right. Shaun runs faster than the pigs, so he can catch them and intercept them, but not so much faster that a lazy player can always win. You need to start running when the pigs do.
While creating this game, I found that you can do this in Scratch, which I didn't know before:
Basically, the 'go to mouse pointer' block, which has a menu in it to choose a sprite to go to, will also take a variable, which can store the name of a sprite to go to. That concept proved to be important because it enables the ball to follow the sprite that is dribbling it. When a sprite takes possession of the ball, it changes the possession variable to its sprite name. The ball always goes to the sprite in that variable name.
You can play my Shaun the Sheep game below (requires Flash, so won't work on Raspberry Pi or iPad). Click the green flag to start. Cursor keys move Shaun. Use Space to shoot at the pigs' goal (on the right of the pitch). Note that the game includes music and sound effects. You can see the code, leave your comments and find the game's page on the Scratch website here. You can also leave a comment below. Find out how you can make your own Shaun the Sheep Scratch game here.
20 June 2014
If you're looking for a fun project this summer holiday, why not make a Scratch game starring BBC TV's Shaun the Sheep? Aardman, the talented team of animators behind Shaun the Sheep, have released a set of Scratch sprites you can use to put Shaun, Shirley, the pigs and some of their surroundings into your Scratch games. It's all part of Shaun's Game Academy, a programme to help people to learn computer game design using Scratch, with a competition for Scratch games created using the Shaun the Sheep sprites.
The sprites have been released in a number of projects on the Scratch website. Some of them don't have any scripts, just sprites in, so they don't do anything. Here's how to get the sprites out of those projects:
- Go into one of the projects in the Scratch editor.
- Click to open the Backpack at the bottom of the screen, under the Scripts Area and the Blocks Palette. You don't need to do this if the Backpack is already open.
- Drag a sprite from the Sprite List (bottom left) into the Backpack (which you've just opened).
- You can now drag that sprite from the Backpack back into the Sprite List (bottom left) to add it into one of your own projects when you're editing it.
- Note that some sprites do have scripts attached, so it's a good idea to delete any scripts you don't need immediately after adding a sprite to your game, to avoid any confusion.
You can also right-click on a sprite in the Sprite List or a sound in the Sounds Palette to save it to a local file. That will put it on your computer, so you can upload it into Scratch again, whether you're using the web version or the desktop version.
I've been having fun making my own game with the sprites, and I'll share that here when I finish it. In the meantime, check out Shaun's Game Academy, and leave me a comment below to tell me what you make! You can also find my own Scratch projects here and find more Scratch resources from my book here.
UPDATED: I've published my game Shaun the Sheep Football.
13 June 2014
There was a story in the news this week about a program that had apparently passed the Turing Test for artificial intelligence. This test basically says that if a person can't tell whether they are chatting to a real person or a piece of software, the software exhibits artificial intelligence. Having heard John Humphrys on Radio 4 chatting to the program, I have to say I wasn't convinced the program would have convinced me it was a human, even a 13-year old one.
If you work co-operatively with the program, you can create a fun simulation of an intelligent conversation, although this is clearly no contender for passing the Turing Test.
I've updated the program to include some new vocabulary and to tweak the priority of some of the other words it knows. I'd be interested to know what other topics and words you use that aren't recognised. I've tried to predict the most obvious ones, but I'm sure I've missed plenty. Chat to Virtual Sean here.