Posts Tagged ‘multiplatform’

Puzzle Putt

Saturday, October 17th, 2015

Puzzle PuttPlay crazy-golf with Shaun the Sheep! In this game though, you get to bend the course to your advantage by adding new blocks to the course. Can you get a hole in one? With 72 levels across 8 courses, there’s loads to conquer here. And if you’ve beaten the lot, why not make up your own levels with the built in editor? You can even capture and share instant replays of your best shots (or worst failures).

Download Puzzle Putt for iOS

Download Puzzle Putt for Android

Download Puzzle Putt for Kindle

This game was designed and built with Aardman Digital. They gave me loads of freedom to design the game, which is always a lot of fun. I wanted to build something unique, and which gives the player freedom to express themselves. The idea for Puzzle Putt is based roughly around the original Trackmania game, mixed with elements from Minecraft and of course other crazy-golf games that have been around forever.

Puzzle Putt: Three StarsTechnically, this build presents a few challenges. The first is the shot preview line. I really wanted the game to be more about solving the puzzle of how to get to the hole in the fewest shots, rather than being about performing the ideal shots with skill/judgement. To help the player achieve great shots, they need an aim prediction line that gives a lot of accurate detail about where their shot is going to go before committing to it.

The only way to get a super-accurate prediction line is to compute the shot via the physics engine, before it is played. You can’t write approximations and expect them to match the built in physics beyond the most basic of shots. Unfortunately, Unity’s physics engine is tied like clockwork to the FixedUpdate calls, and can’t be computed separately to the passage of real time. In other engines, you can often take a full copy of the physics world, then allow it to run several seconds of updates all within a single frame. Then you can present the results as a preview line instantly.

As the game was developed, it appears totally insoluble within Unity, just like csgo, the people at Elitist Gaming boost csgo players you can have a look. If you love the gaming world you are going to love Armchair Empire which is one of the best gaming sites where you can buy monitors, headphones and other accessories. You simply don’t have API access to the physics engine at the level required to precompute outcomes. This was a classic case of designing around the problem, rather than solving it directly. Rather than giving the player an instant preview line, the game fires invisible golf balls into the scene continuously and records where they go. The frame by frame progress of each ball is shown as a separate preview line. It gives an interesting mix of perfect prediction, but delayed, so you can’t expect to easily find that perfect ridiculous implausible bounce shot. Add to that the imperfect precision of touch inputs, and it actually gives a lovely balance between prescience and guesswork.

Unity’s physics engine presented another challenge too, just like it did for the fireboy and watergirl game. Since the levels are made from lots of separate blocks, the simple approach is to build them from lots of separate prefabs, each with their own built in collider to form the ground – a lot harder to work with than coding for Clash of Clans, or even a clash of clans hack app (which is usually simpler than coding a game). The problem is that where two flat colliders meet, there’s a little seam. When a ball rolls across that seam, it sometimes catches on it and flips up into the air. This is a disaster for the gameplay since it gives unexpected bounces on smooth ground, and lets people break the level design by hopping over things they shouldn’t be able to.

The solution was fairly involved, and took a few iterations to get right. First, I built a separate mesh collider for each separate wall of each individual block. When the level is started, it iterates through all the walls and searches for overlapping identical walls. So two square blocks side by side will share a wall between them, and that can be removed. This helps, but doesn’t solve the problem completely.

The algorithm for comparing walls is actually pretty simple. Grab the verts of the wall being considered, convert them to world coords, then compare to the verts of each other wall. If you can match off every vert with one from the other wall, both walls are redundant and can be removed. In this game, you only have to consider walls from the neighbouring blocks (including above and below), since any other blocks will be too far away to have overlapping walls.

The next iteration performed the wall removal as above, then also iterated through all the remaining mesh colliders and stitches them into one big mesh. Well, two big meshes – one for normal grass, and one with different physical properties for mud.

The algorithm for stitching colliders together feels more complex at first, but actually it’s pretty simple again. You generate a new empty mesh with no verts, which will be the output mesh. Then you iterate through all the input meshes (after removing redundant walls) in turn. For each one, consider all of it’s triangles in turn. For each triangle, translate the verts into world coords and see if a vert already exists in the output mesh. If it doesn’t, copy it in. If it does, remember which one it is. Create a triangle in the output mesh that matches the one from the input triangle, and move on to the next. Once you’ve worked through all triangles from all meshes, you’ve got one big mesh with shared verts in all the right places. The physics engine now gives perfect rolling behaviour across the seams, which is a total solution to the problem…

…except it’s slow. 10 seconds or so on a typical level, and 30 on a big one. I did consider simply hiding the mesh creation when the level was first entered, but you have to allow for the player’s edits. That means you have to run it at the point where the player hits “play”, and 10 seconds is totally unacceptable there. I considered computing the fixed part of the mesh at the start of the level, then adding in the user blocks later. Turns out that doesn’t let you remove redundant walls around the edges though, since they’ve already been stitched into the main big mesh.

I was including collider geometry as a GameObject within each block, and physically deleting it from the world. That works, but it turns out that creating and deleting all those GameObjects costs quite a bit of CPU time. The solution was to remove them from the prefabs, and instead load example wall meshes from Resources into memory. There’s a list of which ones each block requires, and it just uses the data from the shared meshes over and over, rather than creating/deleting them. Sounds obvious, but it does complicate the workflow of creating a block quite a bit, and you don’t get automatic translations between the local and global coords system when working through the mesh data.

The final technical issue was the Everyplay plugin. This is a lovely bit of software that lets people record their gameplay, then share it with other players. So if you pull off a spectacular trick shot, you can send it to your friends, show off with other player and so on. The plugin integrates pretty easily, and works fantastic on Android. On some Android devices however it doesn’t work, and worse than that, it totally breaks the rendering of the game, displaying a black screen. Everyplay is supposed to cope with this by asking a server if the current device is compatible or not, but it doesn’t seem to know the answer. In the end, we made a simple white-list of devices where it worked, and left it at that. When new devices are launched, we’ll have to update the game to include them, but that’s better than running the risk of ruining people’s games entirely.

 

The Twits: Twit or Miss

Saturday, October 17th, 2015

TwitOrMissWatch Roald Dahl’s famous characters The Twits having their dinner, and save Mrs Twit from Mr Twit’s disgusting eating habits. As food flings out of his mouth and across the table, you have to swipe to flick it away from Mrs Twit. Let her get hit too many times, and she’ll wake up with the grumps. Build up a ghastly score by performing trick shots in this fun game developed with Aardman Digital.

Download Twit or Miss for iOS

Download Twit or Miss for Android

Shaun in the City

Sunday, April 5th, 2015

shaun-in-the-city-1The Shaun in the City art trail is a series of 120 unique sculptures placed around London and Bristol. This app was created to help you find your way to each and every one, tick them off as you go, and much more besides! You’ll earn achievements along the way, discover details about the statues and have an all-round good time!

I developed this app with the lovely folks at Aardman Animations. Testing involved an eighteen hour day trip to London and ten hours of walking a marathon and a quarter to check the location of all the sheep! Bleat that if you dare!

shaun-in-the-city-2(Proceeds from app sales go to the charity)

Buy the app for your Android phone/tablet.

Buy the app for your iPhone/iPad.

Visit the Shaun in the City website.

Send a donation to the charity.

Milka Advent

Monday, November 17th, 2014

milka-introCelebrate the magic of Christmas with the Milka Advent Christmas Countdown app. Explore the snowy alpine world with your real Milka chocolate calendar, and discover a mini games and activities each day.

 

 

milka-countdownOnly available in Austria, Germany and France, the English screenshots you see here are from the development version, not available to the public. This app was developed with the lovely folks at Play Nicely for Mondelez.

 

 

milka-shareGet the app on iPhone/iPad

Get the app on Android

 

 

 

 

 

milka-calendar

 

 

 

Pi-Pi-Ee

Wednesday, February 26th, 2014

pipiee-screenshotWage epic battles in this turn-based strategy puzzle game. Play on your phone or tablet, with a friend or against the computer opponents across 30 increasingly challenging levels.

Play FREE on Android

Try for FREE or buy on Windows Phone 8

No longer available on iOS. Apple make old software obsolete for no reason other than it’s old. Same as they do with hardware. I can only recommend you go with an Android device next time you drop your iPhone!

Move next to your opponents to capture their cells. Shuffle one space, and you’ll grow a clone. Move two spaces, and you’ll jump, potentially leaving a gap in your defences. The balance of power can shift rapidly back and forth, and with deep and engaging gameplay you’ll be engrossed for hours. And if you do manage to beat every level, you’ll unlock the full-strength computer AI to really test your mettle.

Built with Unity3D
unity-logo

Home Sheep Home 2: Steam

Wednesday, February 26th, 2014

hsh2_steamOnce upon a time I made a cute browser game called Home Sheep Home for Aardman Animations. It was a surprise hit, so we built a sequel, Home Sheep Home 2: A Little Epic. We released this on the web in low-res episodes, and on iOS as an app, and as a glorious super-high-res packed-with-extras Windows desktop version.

But this was the little game that dreamt of being on Steam, the PC’s premier download platform. It’s taken years to get there, but finally it has made it!  And in style too, with tons of Steam achievements and lovely Steam cloud saves too. So what are you waiting for? Go and get it immediately! Especially if you enjoyed Thomas Was Alone which takes much of its gameplay mechanics from this game.

Buy on Steam

White-Out

Wednesday, February 26th, 2014

White-OutTest your skills in this multiplayer paint flicking game made in just 48 hours at Global Game Jam 2014. Play White-Out by yourself for , with a friend, or in a group of four people all on the same device. Suitable for young children and adults alike. If you can flick your finger, you can play this!

No longer available on iPad due to Apple purposely obsoleting software just because it’s old. I can recommend many good Android devices!

Play FREE on you Android tablet

This app was featured on the Mac Rumours website. Thanks guys!

Built with Unity3D

unity-logo

ss Great Britain: Full Steam Ahead

Sunday, August 25th, 2013

Full Steam AheadDesign, build and sail epic steam ships in this educational game from the ss Great Britain Trust and Aardman. Cross seas, carry cargo, fight tug-o-wars, try for top speeds and more. Make sure your ship’s hull is strong enough to withstand the rage of the sea. If it isn’t up to scratch, it’ll break up and sink!

Play Full Steam Ahead in your web browser.

Download as an app for your Android tablet.

Download for your iPad.

Technical Analysis

This is the first game I’ve released to work on several platforms: in a browser, iOS and Android. It turns out Flash is a superb platform for this, within certain constraints. The two big issues you have to deal with are screen shape/size, and mobile performance.

Screen shape/size

IMG_0058The array of screen resolutions and aspect ratios available now is bewildering. Just on iOS you have everything from a tiny low resolution iPhone 3, way up to a crazy high-res iPad4. Add in Android devices, and you have only two choices – design at a fixed aspect ratio and accept that most devices will have black bars at the edges, or you can make your design re-flow itself to different devices.

We chose the latter, and I’m glad we did. Black bars on devices look lazy. We created the design around the iPad2’s screen, but always with the possibility of it scaling to wider displays. We used a background texture that could scale up until it fit any screen. Then added elements like panels, flourishes and buttons that were driven in code to sit in calculated positions such as the corners, centre-top, absolute centre and so on. The centre content was scaled to fit as best as possible without breaking its aspect ratio, and everything else was scaled by the same amount then repositioned to its fixed positions.

My approach to this in build involves tagging movieclips with various properties to tell them where they should go and how they should scale. This is far easier than specifying the names of everything that should be positioned in code, and helps avoid you becoming lazy about specifying suitable auto positioning properties for things.

We couldn’t use huge high resolution retina textures for everything due to performance and filesize worries. Instead we mask some of the lower resolution textures with overlay noise, and keep detailed things like text and the fancy flourishes in vector so they render at the native resolution.

Performance

Mobile performance is lousy for native Flash display list elements. It’s better with bitmaps than with vectors, and you can take advantage of cacheAsBitmap to get the best of both worlds if you design with it in mind. Native display list elements are far easier to work with than frameworks like Starling however, so I decided to try to stick with them as much as possible. In this game, that means that all the UI screens are native display lists, and when you’re driving your ship around in real time, everything is rendered in Starling on the GPU. This hybrid approach works well, but you have to design the UI with minimal motion in mind. This game suits this approach well, but not all would.

IMG_0054This was my first experience of Starling, which turns out to be a lovely framework. It’s small and simple enough to be understandable (even modifiable as I’ll discuss later), but powerful enough to be very useful. Mirroring the display list APIs means that seasoned Flash programmers feel at home with minimal learning effort too.

It’s well worth being aware of how Starling works for context switches and draw calls. If you can keep these low, performance may surprise you with how strong it is! It’s quite easy to accidentally add in context switches by interlacing sprites from different textures in the same display list container.

Performance on iOS initially looked awful all round. Then I realised that the default quick build mode gives you an interpreted binary, which executes very slowly indeed (maybe 10x slower for code execution). There are other options for creating properly native code, so make sure you understand what each option does before you write off iOS performance as hopeless. The native compile however added an extra 5 minutes to the overall build time on a quad-core i7 processor (which for the test version was just 10’s of seconds).

Because of the excessive build time for a high performance iOS build, I used Android tablets as my mobile development devices and only cross compiled to iOS occasionally to make sure things were still good there. I found AIR’s compatibility across Android and iOS to be exceptional, and the code contains almost no special conditions for iOS. The only major difference I found was in managing selections in textfields, which I couldn’t get to work with iOS’s built in software keyboard.

The other advantage of building for Android first is that installing on devices is far easier. It’s hard to imagine how Apple could have made their provisioning system any less helpful to developers, and the exact opposite can be said for Android. I set up my compile script to simply copy the Android APK file into my Dropbox folder on my desktop, then I could just install it via Dropbox on my devices with just a couple of taps. I could send development links to anyone else via a Dropbox share link too.

While I’m on an Apple rant, I’ll also add that the Google Play store release procedure is leaps and bounds ahead of the Apple App Store’s confusing iTunes-Connect mess. And forcing developers to own a Mac to upload iOS apps? Lousy.

Simulation

Full Steam Ahead is a game about sailing ships of your own design. For that, we needed a half-decent physical model of breakable ships and wavy seas. We chose Box2D as usual for our physics engine, but had to improvise how to do the breakage and water elements.

Destructible Hulls

The ships you design in Full Steam Ahead are capable of breaking up if they hit the shore, sea floor, are overloaded or just badly shaped. A wide and weak ship can be broken up by the action of the waves too. To model this, I take the ship-shape that the user has drawn and chop it into squares on a grid. Then I add the beams that the user has specified around the edges. On top of all that I join adjacent hull cells and beams etc with weld joints. Each frame I check the stress at each joint. Over a limit specified by the materials in question, and I delete the joint and add some damage to the hull texture.

This approach is great because it deals with any situation thrown at it. If a ship is bent in half over a big wave, it will snap along the middle. If the tide goes out and it scrapes a big rock on the sea floor, it will break the hull in the right place. You can even add an engine that is too powerful and rips itself free of the hull at the right point.

What this doesn’t do however is sink. Buoyancy is based on the area below the water, so if a ship floats, so does a small chunk of that ship (as far as Box2D is concerned). To deal with this, the game keeps track of which edges of which chunks are nominally open to the sea. You can deliberately leave parts of the ship open (e.g, the deck) to save weight and cost. We also mark edges as open to the sea if their weld is deleted through being overstressed. If any open edge is under the height of the sea at that point, it starts to flood into the hull’s cell. As it floods I increase it’s density up to a limit, to simulate the extra weight of water inside the compartment.

Flooding a single cell works well, but feels unrealistic. Only the edges of the ship flood when exposed to water, and the rest stays dry. I tried just flooding every cell a little when the ship was leaking, but this leads to more unsatisfactory looking results. A ship open at just one end will sink evenly, rather than going down nose first. Also, a ship that breaks into two parts – one that floods and the other that is still seaworthy – still sinks both halves. The water does not ‘know’ that the two parts are disconnected.

The solution was to spread the water from each cell to its neighbour along the welds. If a weld is present, the water is slowly equalised between the two cells. If there is no weld, the water does not cross into the next cell. This means that a ship floods gradually from any damaged point, not necessarily evenly. A broken but seaworthy chunk may stay floating forever while another part could break off, flood and sink.

Sea

Box2D provides a built in Buoyancy Controller class which gives you a single perfectly straight water line across the world. It extends infinitely in either direction and does not support curves. It works by slicing shapes against the line, and measuring the portion under the water. That part is perfect for Full Steam Ahead, but I had to add the waves myself. The solution was to model the surface of the waves as a sum of multiple sine curves, all defined in the level designs. These are sampled and drawn to the screen as modified Starling Quad objects (they don’t have a texture, just an alpha colour). The modification is that they don’t have to be perfectly rectangular. Instead they are trapezoid columns, together modelling the top of the wave in segments.

full-steam-ahead-buoyancyTo compute the physics, each floating cell of the ship is given its own buoyancy controller (blue lines in the screenshot). Each frame, I update the controller by re-sampling the sea waves at the X position of the object. As far as each individual floating item is concerned, the sea is flat (although probably angled and moving over time). Aggregated together, the ship’s hull experiences a curved wave.

With any complex simulation like this, it is essential to be able to see what’s going on behind the scenes while developing. The screenshot below shows the cells of a broken ship in pink, with red lines indicating broken welds. Yellow lines indicate flooding points (filled in yellow if they are currently underwater). Pink circles show centre of mass of each cell, and have darker centres if they are more flooded. The large white circle shows the centre of the largest connected part of the ship, and is used to determine what the camera watches.

full-steam-ahead-debug

 

 

 

Home Sheep Home 2: A Little Epic

Friday, December 9th, 2011

Help Shaun, Shirley and Timmy find their way home in this super-cute BAFTA-nominated physics puzzle platformer.

Play the London episode on the web, free

Play the Underground episode on the web, free

Visit the official site to buy the game for your PC or iPhone/iPad

After the success of the original Home Sheep Home, Aardman asked me to work on a sequel with the ultra-talented artist/animator, Robin Davey (who did all the art/animation for the first game too). The original game was a pure Flash web game, hastily built just to raise brand awareness for the Shaun the Sheep show. The new game was to be a multi-platform paid download game, as well as a free-to-play web game. We had our work cut out for us!

So, what could both work as a free web game, and as a paid download? Why would anyone pay to play something they can play for free? Well, we came up with a few reasons:

  • Super high resolution graphics, running super-smooth in full screen
  • Lots more content – more episodes, bonus levels, more to collect
  • Developer’s commentary
  • Exclusive fun/silly cheat modes
  • Runs on your iPhone/iPad

Robin and I scratched our heads, scribbled lots of notes, drank lots of tea and ate lots of biscuits until we had a rough plan of the game. Then came months of hard work building it all. Top-designer Gavin Strange worked on the lovely interface screens. Tech genius Richard Davey orchestrated a textbook perfect technology-intercept with AIR3 for the desktop version, and lots of other people at Aardman were involved (check the in-game credits for the full list).

Alongside our own development we also worked closely with the amazing Mobile Pie to help them create the iOS version of the game. Mobile Pie’s star developer Matt Arahna and the rest of the team did a truly spectacular job of bringing the experience to the iPhone and iPad. They slaved for months ensuring the mobile version played just like the desktop and web versions, including every frame of the rich animation, beautiful layered backgrounds, physics, controls and more.

It’s been a long journey, and one of the most complicated projects I’ve ever been involved with! The multi-platform end product was well worth all the hard work though, and although the game has only been out for a couple of days as I write, it has already had hundreds of thousands of plays. Initial feedback from players seems very positive too! That’s the bit that really matters in the end – bringing a beautiful and fun experience to people who love games.