Tag Archives: wireframe

Code your own path-following Lemmings in Python | Wireframe issue 17

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/code-your-own-path-following-lemmings-in-python-wireframe-issue-17/

Learn how to create your own obedient lemmings that follow any path put in front of them. Raspberry Pi’s own Rik Cross explains how.

The original Lemmings, first released for the Amiga, quickly spread like a virus to just about every computer and console of the day.

Lemmings

Lemmings is a puzzle-platformer, created at DMA Design, and first became available for the Amiga in 1991. The aim is to guide a number of small lemming sprites to safety, navigating traps and difficult terrain along the way. Left to their own devices, the lemmings will simply follow the path in front of them, but additional ‘special powers’ given to lemmings allow them to (among other things) dig, climb, build, and block in order to create a path to freedom (or to the next level, anyway).

Code your own lemmings

I’ll show you a simple way (using Python and Pygame) in which lemmings can be made to follow the terrain in front of them. The first step is to store the level’s terrain information, which I’ve achieved by using a two-dimensional list to store the colour of each pixel in the background ‘level’ image. In my example, I’ve used the ‘Lemcraft’ tileset by Matt Hackett (of Lost Decade Games) – taken from opengameart.org – and used the Tiled software to stitch the tiles together into a level.

The algorithm we then use can be summarised as follows: check the pixels immediately below a lemming. If the colour of those pixels isn’t the same as the background colour, then the lemming is falling. In this case, move the lemming down by one pixel on the y-axis. If the lemming isn’t falling, then it’s walking. In this case, we need to see whether there is a non-ground, background-coloured pixel in front of the lemming for it to move onto.

Sprites cling to the ground below them, navigating uneven terrain, and reversing direction when they hit an impassable obstacle.

If a pixel is found in front of the lemming (determined by its direction) that is low enough to get to (i.e. lower than its climbheight), then the lemming moves forward on the x-axis by one pixel, and upwards on the y-axis to the new ground level. However, if no suitable ground is found to move onto, then the lemming reverses its direction.

The algorithm is stored as a lemming’s update() method, which is executed for each lemming, each frame of the game. The sample level.png file can be edited, or swapped for another image altogether. If using a different image, just remember to update the level’s BACKGROUND_COLOUR in your code, stored as a (red, green, blue, alpha) tuple. You may also need to increase your lemming climbheight if you want them to be able to navigate a climb of more than four pixels.

There are other things you can do to make a full Lemmings clone. You could try replacing the yellow-rectangle lemmings in my example with pixel-art sprites with their own walk cycle animation (see my article in issue #14), or you could give your lemmings some of the special powers they’ll need to get to safety, achieved by creating flags that determine how lemmings interact with the terrain around them.

Here’s Rik’s code, which gets those path-following lemmings moving about in Python. To get it running on your system, you’ll first need to install Pygame Zero. And to download the full code, go here.

Get your copy of Wireframe issue 17

You can read more features like this one in Wireframe issue 17, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press — delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 17 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Code your own path-following Lemmings in Python | Wireframe issue 17 appeared first on Raspberry Pi.

Recreate the sprite-following Options from Gradius using Python | Wireframe issue 16

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/recreate-the-sprite-following-options-from-gradius-using-python-wireframe-issue-16/

Learn how to create game objects that follow the path of the main player sprite. Raspberry Pi’s own Rik Cross explains all.

Options first appeared in 1985’s Gradius, but became a mainstay of numerous sequels and spin-offs, including the Salamander and Parodius series of games.

Gradius

First released by Konami in 1985, Gradius pushed the boundaries of the shoot-’em-up genre with its varied level design, dramatic boss fights, and innovative power-up system.

One of the most memorable of its power-ups was the Option — a small, drone-like blob that followed the player’s ship and effectively doubled its firepower.

By collecting more power-ups, it was possible to gather a cluster of death-dealing Options, which obediently moved wherever the player moved.

Recreate sprite-following in Python

There are a few different ways of recreating Gradius’ sprite-following, but in this article, I’ll show you a simple implementation that uses the player’s ‘position history’ to place other following items on the screen. As always, I’ll be using Python and Pygame to recreate this effect, and I’ll be making use of a spaceship image created by ‘pitrizzo’ from opengameart.org.

The first thing to do is to create a spaceship and a list of ‘power-up’ objects. Storing the power-ups in a list allows us to perform a simple calculation on a power-up to determine its position, as you’ll see later. As we’ll be iterating through the power-ups stored in a list, there’s no need to create a separate variable for each. Instead, we can use list comprehension to create the power-ups:

powerups = [Actor(‘powerup’) for p in range(3)]

The player’s position history will be a list of previous positions, stored as a list of (x,y) tuples. Each time the player’s position changes, the new position is added to the front of the list (as the new first element). We only need to know the spaceship’s recent position history, so the list is also truncated to only contain the 100 most recent positions. Although not necessary, the following code can be added to allow you to see a selection (in this case every fifth) of these previous positions:

for p in previouspositions[::5]:

screen.draw.filled_circle(p, 2, (255,0,0))

Plotting the spaceship’s position history.

Each frame of the game, this position list is used to place each of the power-ups. In our Gradius-like example, we need each of these objects to follow the player’s spaceship in a line, as if moving together in a single-file queue. To achieve this effect, a power-up’s position is determined by its position in the power-ups list, with the first power-up in the list taking up a position nearest to the player. In Python, using enumerate when iterating through a list allows us to get the power-up’s position in the list, which can then be used to determine which position in the player’s position history to use.

newposition = previouspositions[(i+1)*20]

So, the first power-up in the list (element 0 in the list) is placed at the coordinates of the twentieth ((0+1)*20) position in the spaceship’s history, the second power-up at the fourtieth position, and so on. Using this simple calculation, elements are equally spaced along the spaceship’s previous path. The only thing to be careful of here is that you have enough items in the position history for the number of items you want to follow the player!

Power-ups following a player sprite, using the player’s position history.

This leaves one more question to answer; where do we place these power-ups initially, when the spaceship has no position history? There are a few different ways of solving this problem, but the simplest is just to generate a fictitious position history at the beginning of the game. As I want power-ups to be lined up behind the spaceship initially, I again used list comprehension

to generate a list of 100 positions with ever-decreasing x-coordinates.

previouspositions = [(spaceship.x - i*spaceship.speed,spaceship.y) for i in range(100)]

With an initial spaceship position of (400,400) and a spaceship.speed of 4, this means the list will initially contain the following coordinates:

previouspositions = [(400,400),(396,400),(392,400),(388,400),...]

Storing our player’s previous position history has allowed us to create path-following power-ups with very little code. The idea of storing an object’s history can have very powerful applications. For example, a paint program could store previous commands that have been executed, and include an ‘undo’ button that can work backwards through the commands.

Here’s Rik’s code, which recreates those sprite-following Options in Python. To get it running on your system, you’ll first need to install Pygame Zero. And to download the full code, go here.

Get your copy of Wireframe issue 16

You can read more features like this one in Wireframe issue 16, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press — delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 16 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Recreate the sprite-following Options from Gradius using Python | Wireframe issue 16 appeared first on Raspberry Pi.

Coding an isometric game map | Wireframe issue 15

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/coding-an-isometric-game-map-wireframe-issue-15/

Isometric graphics give 2D games the illusion of depth. Mark Vanstone explains how to make an isometric game map of your own.

Published by Quicksilva in 1983, Ant Attack was one of the earliest games to use isometric graphics. And you threw grenades at giant ants. It was brilliant.

Isometric projection

Most early arcade games were 2D, but in 1982, a new dimension emerged: isometric projection. The first isometric game to hit arcades was Sega’s pseudo-3D shooter, Zaxxon. The eye-catching format soon caught on, and other isometric titles followed: Q*bert came out the same year, and in 1983 the first isometric game for home computers was published: Ant Attack, written by Sandy White.

Ant Attack

Ant Attack was first released on the ZX Spectrum, and the aim of the game was for the player to find and rescue a hostage in a city infested with giant ants. The isometric map has since been used by countless titles, including Ultimate Play The Game’s classics Knight Lore and Alien 8, and my own educational history series ArcVenture.

Let’s look at how an isometric display is created, and code a simple example of how this can be done in Pygame Zero — so let’s start with the basics. The isometric view displays objects as if you’re looking down at 45 degrees onto them, so the top of a cube looks like a diamond shape. The scene is made by drawing cubes on a diagonal grid so that the cubes overlap and create solid-looking structures. Additional layers can be used above them to create the illusion of height.

Blocks are drawn from the back forward, one line at a time and then one layer on top of another until the whole map is drawn.

The cubes are actually two-dimensional bitmaps, which we start printing at the top of the display and move along a diagonal line, drawing cubes as we go. The map is defined by a three-dimensional list (or array). The list is the width of the map by the height of the map, and has as many layers as we want to represent in the upward direction. In our example, we’ll represent the floor as the value 0 and a block as value 1. We’ll make a border around the map and create some arches and pyramids, but you could use any method you like — such as a map editor — to create the map data.

To make things a bit easier on the processor, we only need to draw cubes that are visible in the window, so we can do a check of the coordinates before we draw each cube. Once we’ve looped over the x, y, and z axes of the data list, we should have a 3D map displayed. The whole map doesn’t fit in the window, and in a full game, the map is likely to be many times the size of the screen. To see more of the map, we can add some keyboard controls.

Here’s Mark’s isometric map, coded in Python. To get it running on your system, you’ll first need to install Pygame Zero. And to download the full code, visit our Github repository here.

If we detect keyboard presses in the update() function, all we need to do to move the map is change the coordinates we start drawing the map from. If we start drawing further to the left, the right-hand side of the map emerges, and if we draw the map higher, the lower part of the map can be seen.

We now have a basic map made of cubes that we can move around the window. If we want to make this into a game, we can expand the way the data represents the display. We could add differently shaped blocks represented by different numbers in the data, and we could include a player block which gets drawn in the draw() function and can be moved around the map. We could also have some enemies moving around — and before we know it, we’ll have a game a bit like Ant Attack.

Tiled

When writing games with large isometric maps, an editor will come in handy. You can write your own, but there are several out there that you can use. One very good one is called Tiled and can be downloaded free from mapeditor.org. Tiled allows you to define your own tilesets and export the data in various formats, including JSON, which can be easily read into Python.

Get your copy of Wireframe issue 15

You can read more features like this one in Wireframe issue 15, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press — delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 15 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Coding an isometric game map | Wireframe issue 15 appeared first on Raspberry Pi.

Make a Donkey Kong–style walk cycle | Wireframe issue 14

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/make-a-donkey-kong-style-walk-cycle-wireframe-issue-14/

Effective animation gave Donkey Kong barrels of personality. Raspberry Pi’s own Rik Cross explains how to create a similar walk cycle.

Donkey Kong wasn’t the first game to feature an animated character who could walk and jump, but on its release in 1981, it certainly had more personality than the games that came before it. You only have to compare Donkey Kong to another Nintendo arcade game that came out just two years earlier — the half-forgotten top-down shooter Sheriff — to see how quickly both technology and pixel art moved on in that brief period. Although simple by modern standards, Donkey Kong’s hero Jumpman (later known as Mario) packed movement and personality into just a few frames of animation.

In this article, I’ll show you how to use Python and Pygame to create a character with a simple walk cycle animation like Jumpman’s in Donkey Kong. The code can, however, be adapted for any game object that requires animation, and even for multiple game object animations, as I’ll explain later.

Jumpman’s (aka Mario’s) walk cycle comprised just three frames of animation.

Firstly, we’ll need some images to animate. As this article is focused on the animation code and not the theory behind creating walk cycle images, I grabbed some suitable images created by Kenney Vleugels and available at opengameart.org.

Let’s start by animating the player with a simple walk cycle. The two images to be used in the animation are stored in an images list, and an animationindex variable keeps track of the index of the current image in the list to display. So, for a very simple animation with just two different frames, the images list will contain two different images:

images = [‘walkleft1’,‘walkleft2’

To achieve a looping animation, the animationindex is repeatedly incremented, and is reset to 0 once the end of the images list is reached. Displaying the current image can then be achieved by using the animationindex to reference and draw the appropriate image in the animation cycle:

self.image = self.images[self.state][self.animationindex]

A list of images along with an index is used to loop through an animation cycle.

The problem with the code described so far is that the animationindex is incremented once per frame, and so the walk cycle will happen way too quickly, and won’t look natural. To solve this problem, we need to tell the player to update its animation every few frames, rather than every frame. To achieve this, we need another couple of variables; I’ll use animationdelay to store the number of frames to skip between displayed images, and animationtimer to store the number of frames since the last image change.

Therefore, the code needed to animate the player becomes:

self.animationtimer += 1
if self.animationtimer >= self.animationdelay:
self.animationtimer = 0
self.animationindex += 1
if self.animationindex > len(self.images) - 1:
self.animationindex = 0
self.image = self.images[self.animationindex]

So we have a player that appears to be walking, but now the problem is that the player walks constantly, and always in the same direction! The rest of this article will show you how to solve these two related problems.

There are a few different ways to approach this problem, but the method I’ll use is to make use of game object states, and then have different animations for each state. This method is a little more complicated, but it’s very adaptable.

The first thing to do is to decide on what the player’s ‘states’ might be — stand, walkleft, and walkright will do as a start. Just as we did with our previous single animation, we can now define a list of images for each of the possible player’s states. Again, there are lots of ways of structuring this data, but I’ve opted for a Python dictionary linking states and image lists:

self.images = { ‘stand’ : [‘stand1’],
‘walkleft’ : [‘walkleft1’,‘walkleft2’],
‘walkright’ : [‘walkright1’,‘walkright2’]
}

The player’s state can then be stored, and the correct image obtained by using the value of state along with the animationindex:

self.image = self.images[self.state][self.animationindex]

The correct player state can then be set by getting the keyboard input, setting the player to walkleft if the left arrow key is pressed or walkright if the right arrow key is pressed. If neither key is pressed, the player can be set to a stand state; the image list for which contains a single image of the player facing the camera.

Animation cycles can be linked to player ‘states’.

For simplicity, a maximum of two images are used for each animation cycle; adding more images would create a smoother or more realistic animation.

Using the code above, it would also be possible to easily add additional states for, say, jumping or fighting enemies. You could even take things further by defining an Animation() object for each player state. This way, you could specify the speed and other properties (such as whether or not to loop) for each animation separately, giving you greater flexibility.

Here’s Rik’s animated walk cycle, coded in Python. To get it running on your system, you’ll first need to install Pygame Zero. And to download the full code, go here.

Get your copy of Wireframe issue 14

You can read more features like this one in Wireframe issue 14, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press — delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 14 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Make a Donkey Kong–style walk cycle | Wireframe issue 14 appeared first on Raspberry Pi.

Raspberry Pi Press: what’s on our newsstand?

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/raspberry-pi-press-newsstand/

Raspberry Pi Press, the publishing branch of Raspberry Pi Trading, produces a great many magazines and books every month. And in keeping with our mission to make computing and digital making as accessible as possible to everyone across the globe, we make the vast majority of our publications available as free PDFs from the day we release new print versions.

We recently welcomed Custom PC to the Press family and we’ve just published the new-look Custom PC 190. So this is a perfect time to showcase the full catalogue of Raspberry Pi Press publications, to help you get the most out of what we have on offer.

The MagPi magazine

The MagPi was originally created by a group of Raspberry Pi enthusiasts from the Raspberry Pi forum who wanted to make a magazine that the whole community could enjoy. Packed full of Pi-based projects and tutorials, and Pi-themed news and reviews, The MagPi now sits proudly upon the shelves of Raspberry Pi Press as the official Raspberry Pi magazine.

The MagPi magazine issue 81

Visit The MagPi magazine online, and be sure to follow them on Twitter and subscribe to their YouTube channel.

HackSpace magazine

The maker movement is growing and growing as ever more people take to sheds and makerspaces to hone their skills in woodworking, blacksmithing, crafting, and other creative techniques. HackSpace magazine brings together the incredible builds of makers across the world with how-to guides, tips and advice — and some utterly gorgeous photography.

Visit the HackSpace magazine website, and follow their Twitter account and Instagram account.

Wireframe magazine

“Lifting the lid on video games”, Wireframe is a gaming magazine with a difference. Released bi-weekly, Wireframe reveals to readers the inner workings of the video game industry. Have you ever wanted to create your own video game? Wireframe also walks you through how you can do it, in their ‘The Toolbox’ section, which features tutorials from some of the best devs in the business.

Follow Wireframe magazine on Twitter, and learn more on their website.

Hello World magazine

Hello World is our free magazine for educators who teach computing and digital making, and we produce it in association with Computing at Schools and the BCS Academy of Computing. Full of lesson plans and features from teachers in the field, Hello World is a unique resource for everyone looking to bring computing into the classroom, and for anyone interested in computing and digital making education.

Hello World issue 8

Educators in the UK can subscribe to have Hello World delivered for free to their door; if you’re based somewhere else, you can download the magazine for free from the day of publication, or purchase it via the Raspberry Pi Press online store. Follow Hello World on Twitter and visit the website for more.

Custom PC magazine

New to Raspberry Pi Press, Custom PC is the UK’s best-selling magazine for PC hardware, overclocking, gaming, and modding. With monthly in-depth reviews, special features, and step-by-step guides, Custom PC is the go-to resource for turning your computer up to 11.

Visit the shiny new Custom PC website, and be sure to follow them on Twitter.

Books

Magazines aren’t our only jam: Raspberry Pi Press also publishes a wide variety of books, from introductions to topics like the C programming language and Minecraft on your Pi, to our brand-new Raspberry Pi Beginner’s Guide and the Code Club Book of Scratch.

An Introduction to C and GUI programming by Simon Long


We also bridge the gap between our publications with one-off book/magazine hybrids, such as HackSpace magazine’s Book of Making and Wearable Tech Projects, and The MagPi’s Raspberry Pi Projects Book series.



Getting your copies

If you’d like to support our educational mission at the Raspberry Pi Foundation, you can subscribe to our magazines, and you can purchase copies of all our publications via the Raspberry Pi Press website, from many high street newsagents, or from the Raspberry Pi Store in Cambridge. And most of our publications are available as free PDFs so you can get your hands on our magazines and books instantly.

Whichever of our publications you choose to read, and however you choose to read them, we’d love to hear what you think of our Raspberry Pi Press offerings, and we hope you enjoy them all.

The post Raspberry Pi Press: what’s on our newsstand? appeared first on Raspberry Pi.

Create an arcade-style zooming starfield effect | Wireframe issue 13

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/create-an-arcade-style-zooming-starfield-effect-wireframe-issue-13/

Unparalleled depth in a 2D game: PyGame Zero extraordinaire Daniel Pope shows you how to recreate a zooming starfield effect straight out of the eighties arcade classic Gyruss.

The crowded, noisy realm of eighties amusement arcades presented something of a challenge for developers of the time: how can you make your game stand out from all the other ones surrounding it? Gyruss, released by Konami in 1983, came up with one solution. Although it was yet another alien blaster — one of a slew of similar shooters that arrived in the wake of Space Invaders, released in 1978 — it differed in one important respect: its zooming starfield created the illusion that the player’s craft was hurtling through space, and that aliens were emerging from the abyss to attack it.

This made Gyruss an entry in the ‘tube shooter’ genre — one that was first defined by Atari’s classic Tempest in 1981. But where Tempest used a vector display to create a 3D environment where enemies clambered up a series of tunnels, Gyruss used more common hardware and conventional sprites to render its aliens on the screen. Gyruss was designed by Yoshiki Okamoto (who would later go on to produce the hit Street Fighter II, among other games, at Capcom), and was born from his affection for Galaga, a 2D shoot-’em-up created by Namco.

Under the surface, Gyruss is still a 2D game like Galaga, but the cunning use of sprite animation and that zooming star effect created a sense of dynamism that its rivals lacked. The tubular design also meant that the player could move in a circle around the edge of the play area, rather than moving left and right at the bottom of the screen, as in Galaga and other fixed-screen shooters like it. Gyruss was one of the most popular arcade games of its period, probably in part because of its attention-grabbing design.

Here’s Daniel Pope’s example code, which creates a Gyruss-style zooming starfield effect in Python. To get it running on your system, you’ll first need to install Pygame Zero — find installation instructions here, and download the Python code here.

The code sample above, written by Daniel Pope, shows you how a zooming star field can work in PyGame Zero — and how, thanks to modern hardware, we can heighten the sense of movement in a way that Konami’s engineers couldn’t have hoped to achieve about 30 years ago. The code generates a cluster of stars on the screen, and creates the illusion of depth and movement by redrawing them in a new position in a randomly chosen direction each frame.

At the same time, the stars gradually increase their brightness over time, as if they’re getting closer. As a modern twist, Pope has also added an extra warp factor: holding down the Space bar increases the stars’ velocity, making that zoom into space even more exhilarating.

Get your copy of Wireframe issue 13

You can read the rest of the feature in Wireframe issue 13, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press — delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 13 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusive offers and giveaways. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Create an arcade-style zooming starfield effect | Wireframe issue 13 appeared first on Raspberry Pi.

Recreate iconic 1980s game explosions | Wireframe issue 12

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/recreate-bombermans-iconic-explosions-wireframe-issue-12/

Rik Cross, Senior Learning Manager here at the Raspberry Pi Foundation, shows you how to recreate the deadly explosions in the classic game, Bomberman.

An early incarnation of Bomberman on the NES; the series is still going strong today under Konami’s wing.

Creating Bomberman

Bomberman was first released in the early 1980s as a tech demo for a BASIC compiler, but soon became a popular series that’s still going today. Bomberman sees players use bombs to destroy enemies and uncover doors behind destructible tiles. In this article, I’ll show you how to recreate the bombs that explode in four directions, destroying parts of the level as well as any players in their path!

The game level is a tilemap stored as a two-dimensional array. Each tile in the map is a Tile object, which contains the tile type, and corresponding image. For simplicity, a tile can be set to one of five types; GROUND, WALL, BRICK, BOMB, or EXPLOSION. In this example code, BRICK and GROUND can be exploded with bombs, but WALL cannot, but of course, this behaviour can be changed.

Each Tile object also has a timer, which is decremented each frame of the game. When a tile’s timer reaches 0, an action is carried out, which is dependent on the tile type. BOMB tiles (and surrounding tiles) turn into EXPLOSION tiles after a short delay, and EXPLOSION tiles eventually turn back into GROUND. At the start of the game, the tilemap for the level is generated, in this case consisting of mostly GROUND, with some WALL and a couple of BRICK tiles. The player starts off in the top-left tile, and moves by using the arrow keys. Pressing the SPACE key will place a bomb in the player’s current tile, which is achieved by setting the Tile at the player’s position to BOMB. The tile’s timer is also set to a small number, and once this timer is decremented to 0, the bomb tile and the tiles around it are set to EXPLOSION.

Here’s Rik’s example code, which recreates Bomberman’s explosions in Python. To get it running on your system, you’ll first need to install Pygame Zero — you can find full instructions here. And you can download the code here.

The bomb explodes outwards in four directions, with a range determined by the RANGE, which in our code is 3. As the bomb explodes out to the right, for example, the tile to the right of the bomb is checked. If such a tile exists (i.e. the position isn’t out of the level bounds) and can be exploded, then the tile’s type is set to EXPLOSION and the next tile to the right is checked. If the explosion moves out of the level bounds, or hits a WALL tile, then the explosion will stop radiating in that direction. This process is then repeated for the other directions.

There’s a nice trick for exploding the bomb without repeating the code four times, and it relies on the sine and cosine values for the four direction angles. The angles are 0° (up), 90° (right), 180° (down) and 270° (left). When exploding to the right (at an angle of 90°), sin(90) is 1 and cos(90) is 0, which corresponds to the offset direction on the x- and y-axis respectively. These values can be multiplied by the tile offset, to explode the bomb in all four directions.

Get your copy of Wireframe issue 12

You can read the rest of the feature in Wireframe issue 12, available now at Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from Raspberry Pi Press – delivery is available worldwide. And if you’d like a handy digital version of the magazine, you can also download issue 12 for free in PDF format.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives. Subscribe on the Wireframe website to save up to 49% compared to newsstand pricing!

The post Recreate iconic 1980s game explosions | Wireframe issue 12 appeared first on Raspberry Pi.

Coding Breakout’s brick-breaking action | Wireframe #11

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/coding-breakouts-brick-breaking-action-wireframe-11/

Atari’s Breakout was one of the earliest video game blockbusters. Here’s how to recreate it in Python.

The original Breakout, designed by Nolan Bushnell and Steve Bristow, and famously built by a young Steve Wozniak.

Atari Breakout

The games industry owes a lot to the humble bat and ball. Designed by Allan Alcorn in 1972, Pong was a simplified version of table tennis, where the player moved a bat and scored points by ricocheting a ball past their opponent. About four years later, Atari’s Nolan Bushnell and Steve Bristow figured out a way of making Pong into a single-player game. The result was 1976’s Breakout, which rotated Pong’s action 90 degrees and replaced the second player with a wall of bricks.

Points were scored by deflecting the ball off the bat and destroying the bricks; as in Pong, the player would lose the game if the ball left the play area. Breakout was a hit for Atari, and remains one of those game ideas that has never quite faded from view; in the 1980s, Taito’s Arkanoid updated the action with collectible power-ups, multiple stages with different layouts of bricks, and enemies that disrupted the trajectory of the player’s ball.

Breakout had an impact on other genres too: game designer Tomohiro Nishikado came up with the idea for Space Invaders by switching Breakout’s bat with a base that shot bullets, while Breakout’s bricks became aliens that moved and fired back at the player.

Courtesy of Daniel Pope, here’s a simple Breakout game written in Python. To get it running on your system, you’ll first need to install Pygame Zero. And download the code for Breakout here.

Bricks and balls in Python

The code above, written by Daniel Pope, shows you just how easy it is to get a basic version of Breakout up and running in Python, using the Pygame Zero library. Like Atari’s original, this version draws a wall of blocks on the screen, sets a ball bouncing around, and gives the player a paddle, which can be controlled by moving the mouse left and right. The ball physics are simple to grasp too. The ball has a velocity, vel – which is a vector, or a pair of numbers: vx for the x direction and vy for the y direction.

The program loop checks the position of the ball and whether it’s collided with a brick or the edge of the play area. If the ball hits the left side of the play area, the ball’s x velocity vx is set to positive, thus sending it bouncing to the right. If the ball hits the right side, vx is set to a negative number, so the ball moves left. Likewise, when the ball hits the top or bottom of a brick, we set the sign of the y velocity vy, and so on for the collisions with the bat and the top of the play area and the sides of bricks. Collisions set the sign of vx and vy but never change the magnitude. This is called a perfectly elastic collision.

To this basic framework, you could add all kinds of additional features: a 2012 talk by developers Martin Jonasson and Petri Purho, which you can watch on YouTube here, shows how the Breakout concept can be given new life with the addition of a few modern design ideas.

You can read this feature and more besides in Wireframe issue 11, available now in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us – worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subscriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post Coding Breakout’s brick-breaking action | Wireframe #11 appeared first on Raspberry Pi.

Coding Pang’s sprite spawning mechanic | Wireframe #10

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/pang-sprite-spawning-wireframe-10/

Rik Cross, Senior Learning Manager here at Raspberry Pi, shows you how to recreate the spawning of objects found in the balloon-bursting arcade gem Pang.

Pang: bringing balloon-hating to the masses since 1989.

Capcom’s Pang

Programmed by Mitchell and distributed by Capcom, Pang was first released as an arcade game in 1989, but was later ported to a whole host of home computers, including the ZX Spectrum, Amiga, and Commodore 64. The aim in Pang is to destroy balloons as they bounce around the screen, either alone or working together with another player, in increasingly elaborate levels. Destroying a balloon can sometimes also spawn a power-up, freezing all balloons for a short time or giving the player a better weapon with which to destroy balloons.

Initially, the player is faced with the task of destroying a small number of large balloons. However, destroying a large balloon spawns two smaller balloons, which in turn spawns two smaller balloons, and so on. Each level is only complete once all balloons have been broken up and completely destroyed. To add challenge to the game, different-sized balloons have different attributes – smaller balloons move faster and don’t bounce as high, making them more difficult to destroy.

Rik’s spawning balloons, up and running in Pygame Zero. Hit space to divide them into smaller balloons.

Spawning balloons

There are a few different ways to achieve this game mechanic, but the approach I’ll take in my example is to use various features of object orientation (as usual, my example code has been written in Python, using the Pygame Zero library). It’s also worth mentioning that for brevity, the example code only deals with simple spawning and destroying of objects, and doesn’t handle balloon movement or collision detection.

The base Enemy class is simply a subclass of Pygame Zero’s Actor class, including a static enemies list to keep track of all enemies that exist within a level. The Enemy subclass also includes a destroy() method, which removes an enemy from the enemies list and deletes the object.

There are then three further subclasses of the Enemy class, called LargeEnemy, MediumEnemy, and SmallEnemy. Each of these subclasses are instantiated with a specific image, and also include a destroy() method. This method simply calls the same destroy() method of its parent Enemy class, but additionally creates two more objects nearby — with large enemies spawning two medium enemies, and medium enemies spawning two small enemies.

Wireframe 10 Pang

Here’s Rik’s example code, which recreates Pang’s spawning balloons in Python. To get it running on your system, you’ll first need to install Pygame Zero – you can find full instructions here. And you can download the code here.

In the example code, initially two LargeEnemy objects are created, with the first object in the enemies list having its destroy() method called each time the Space key is pressed. If you run this code, you’ll see that the first large enemy is destroyed and two medium-sized enemies are created. This chain reaction of destroying and creating enemies continues until all SmallEnemy objects are destroyed (small enemies don’t create any other enemies when destroyed).

As I mentioned earlier, this isn’t the only way of achieving this behaviour, and there are advantages and disadvantages to this approach. Using subclasses for each size of enemy allows for a lot of customisation, but could get unwieldy if much more than three enemy sizes are required. One alternative is to simply have a single Enemy class, with a size attribute. The enemy’s image, the entities it creates when destroyed, and even the movement speed and bounce height could all depend on the value of the enemy size.

You can read the rest of the feature in Wireframe issue 10, available now in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us – worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subscriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post Coding Pang’s sprite spawning mechanic | Wireframe #10 appeared first on Raspberry Pi.

Coding Space Invaders’ disintegrating shields | Wireframe #9

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/coding-space-invaders-disintegrating-shields-wireframe-9/

They add strategy to a genre-defining shooter. Andrew Gillett lifts the lid on Space Invaders’ disintegrating shields.

Wireframe 9 Space Invaders

Released in 1978, Space Invaders introduced ideas so fundamental to video games that it’s hard to imagine a time before them. And it did this using custom-made hardware which by today’s standards is unimaginably slow.

Space Invaders ran on an Intel 8080 CPU operating at 2MHz. With such meagre processing power, merely moving sprites around the screen was a struggle. In modern 2D games, at the start of each frame the entire screen is reset, then all objects are displayed.

For Space Invaders’ hardware, this process would have been too slow. Instead, each time a sprite needs to move, the game first erases the sprite from the screen, then redraws it in the new position. The game also updates only one alien per frame — which leads to the effect of the aliens moving faster when there are fewer of them. These techniques cut down the number of pixels which need to be updated each frame, from nearly 60,000 to around a hundred.

Wireframe 9 Space Invaders

One of Space Invaders’ most notable features is its four shields. These provide shelter from enemy fire, but deteriorate after repeated hits. The player can take advantage of the shields’ destructible nature — by repeatedly firing at the same place on a shield’s underside, a narrow gap can be created which can then be used to take out enemies. (Of course, the player can also be shot through the same gap.)

The system of updating only the minimum necessary number of pixels works well as long as there’s no need for objects to overlap. In the case of the shields, though, what happens when objects do overlap is fundamental to how they work. Whenever a shot hits something, it’s replaced by an explosion sprite. A few frames later, the explosion sprite is deleted from the screen. If the explosion sprite overlapped with a shield, that part of the shield is also deleted.

Wireframe 9 Space Invaders

Here’s a code snippet that shows Andrew’s Space Invaders-style disintegrating shields working in Python. To get it running on your system, you’ll need to install Pygame Zero — you can find full instructions here. And download the above code here.

The code to the right displays four shields, and then bombards them with a series of shots which explode on impact. I’m using sprites which have been scaled up by ten, to make it easier to see what’s going on.

We first create two empty lists — one to hold details of any shots on screen, as well as explosions. These will be displayed on the screen every frame. Each entry in the shots list will be a dictionary data structure containing three values: a position, the sprite to be displayed, and whether the shot is in ‘exploding’ mode — in which case it’s displayed in the same position for a few frames before being deleted.

The second list, to_delete, is for sprites which need to be deleted from the screen. For simplicity, I’m using separate copies of the shot and explosion sprites where the white pixels have been changed to black (the other pixels in these sprites are set as transparent).

The function create_random_shot is called every half-second. The combination of dividing the maximum value by ten, choosing a random whole number between zero and the maximum value, and then multiplying the resulting random number by ten, ensures that the chosen X coordinate is a multiple of ten.


Wireframe 9 Space Invaders
Wireframe 9 Space Invaders

Andrew’s Space Invaders shields up and running in Pygame Zero.

In the draw function, we first check to see if it’s the first frame, as we only want to display the shields on that frame. The screen.blit method is used to display sprites, and Pygame Zero’s images object is used to specify which sprite should be displayed. We then display all sprites in the to_delete list, after which we reset it to being an empty list. Finally we display all sprites in the shots list.

Wireframe 9 Space Invaders

In the update function, we go through all sprites in the shots list, in reverse order. Going through the list backwards avoids problems that can occur when deleting items from a list inside a for loop. For each shot, we first check to see if it’s in ‘exploding’ mode. If so, its timer is reduced each frame — when it hits zero we add the shot to the to_delete list, then delete it from shots.

If the item is a normal shot rather than an explosion, we add its current position to to_delete, then update the shot’s position to move the sprite down the screen. We next check to see if the sprite has either gone off the bottom of the screen or collided with something. Pygame’s get_at method gives us the colour of a pixel at a given position. If a collision occurs, we switch the shot into ‘exploding’ mode — the explosion sprite will be displayed for five frames.

You can read the rest of the feature in Wireframe issue 9, available now in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us – worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subscriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post Coding Space Invaders’ disintegrating shields | Wireframe #9 appeared first on Raspberry Pi.

How musical game worlds are made | Wireframe #8

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/how-musical-game-worlds-are-made-wireframe-8/

88 Heroes composer Mike Clark explains how music and sound intertwine to create atmospheric game worlds in this excerpt from Wireframe issue 8, available now.

Music for video games is often underappreciated. When I first started writing music in my bedroom, it took me a while to realise how much I was influenced by the worlds that came from my tiny CRT TV. A couple of years ago, I was lucky enough to be approached by Bitmap Bureau, an indie startup who hired me to compose the music for their first game, 88 Heroes.

88 Heroes is a platformer styled like a Saturday morning cartoon. Interestingly, cartoon soundtracks have a lot in common with those for stage productions: short musical cues accompany the actions on screen, so if someone violently falls downstairs, you hear a piano rolling down the keys. This is called ‘mickey mousing’ in cartoons, but we hear similar things in film soundtracks.

Take Raiders of the Lost Ark, scored by John Williams: for every heroic rope swing, leap of faith, or close encounter with danger, the main theme can be heard powering through the dissonances and changing rhythms. It fills the audience with hope and becomes synonymous with the lead character – we want to see him succeed. Let’s not forget the title theme. Every time you see the Star Wars logo, does that grand title theme play in your head? It’s the same with video games. The challenge here, of course, is that players often leave the title screen after three seconds.

Three seconds is all you need though. Take Super Mario World’s soundtrack, composed by Koji Kondo. Many of its levels have the same leading melody, which changes subtly in tonality and rhythm to create the appropriate mood. The most repeating part of the melody is four bars long, but we hear it in so many forms that we only need the first two bars to know where it’s from. In classical music, this is called ‘variations on a theme’. In video games, we call it a ‘sonic identity’.

Action platformer 88 Heroes, featuring music by Mike Clark.

How a picture should ‘sound’

Sonic identity informed my approach to the 88 Heroes soundtrack. The title screen tells us that an unknown group is going to save the day. I first thought about unlikely heroes who end up on an adventure, and Back to the Future, scored by Alan Silvestri, sprang to mind. The second inspiration came from traditional superheroes, like Superman. I composed a melody which travels between the first and fifth notes in the scale (in this case C and G), with little flourishes of the notes in-between. It’s a triumphant, heroic melody.

This concept helps to connect these worlds beyond their visuals. It took a long time for games to evolve into the cohesive open-world sandboxes or MMOs we see today; the technology that masked loading screens to create a seamless experience was unheard of in the 1990s, so a melody that you hear in different ‘costumes’ gives these games a sense of cohesion.

Intelligent instruments

What if you have levels (or worlds) so big that some areas need to be loaded? That’s where non-linear composition comes in. Banjo-Kazooie, released for the N64 in 1998, was among the first 3D games to feature dynamic music. It used a technique called MIDI channel fading. MIDI stands for Musical Instrument Digital Interface; think of it as a universal language for music that is played back in real time by the hardware. As you walk into caves, fly in the sky, or move near certain characters, instruments fade in and out using the different MIDI channels to mimic the atmosphere, give the player an audio cue, and build and release tension.

Learning how to write music that changes as you play might seem impossible at first, but it becomes second nature once you understand the relationship between every instrument in your composition. Many digital audio workstations, like Logic and FL Studio, let you import MIDI data for a song (so you have all the notes in front of you) and set the instruments yourself. Try slowly fading out or muting certain tracks altogether, and listen to how the mood changes. What could this change represent in a video game? It’s like when you’re riding Yoshi in many of the Mario games; the fast bongos come in to represent the quick-footed dinosaur as he dashes at high speeds.

Undertale’s soundtrack blends analogue synth instruments with a plethora of real instruments to help create emotion.

Music is used to evoke emotions that wouldn’t be possible with visuals alone. Beep: A Documentary History of Game Sound shows a six-second video of a boat accompanied by two soundtracks; one is a light and happy guitar piece, the other a grating, scary, orchestral dissonance. Through these two extremes, the music creates the mood by itself. I remember playing Metroid Prime and finding the Chozo Ghost enemies rather scary, not because of their appearance, but because of the unnerving music that accompanies them. Music and sound design are one and the same. Think about what feelings you can create by taking music away entirely — it’s a great way to create tension before a boss battle or pivotal plot point, and it really works. In Undertale, scored by Toby Fox, there are times when the music stops so abruptly during NPC dialogue that you feel shivers down your spine.

So, what if you’re trying to come up with some game music, and you have writer’s block? Well, the next time you play a new game, turn the sound off. As you’re playing, focus on how the story, art, or characters make you feel, and focus on the emotions the game is trying to convey. Then, think of a time when a song made you feel happy, sad, joyful, anxious, or even frightened. Maybe you can use the music to create the mood you want for that game, as opposed to what the game makes you feel. By finding these emotions and understanding how they can change, you’ll be able to write a score that helps strengthen the immersion, escapism, and player investment in your game.

You can read the rest of the feature in Wireframe issue 8, available now in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us – worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

Markets, moggies, and making in Wireframe issue 8

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subcriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post How musical game worlds are made | Wireframe #8 appeared first on Raspberry Pi.

Inside the Dreamcast homebrew scene | Wireframe issue 7

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/wireframe-7-inside-dreamcast-homebrew-scene/

Despite its apparent death 17 years ago, the Sega Dreamcast still has a hardcore group of developers behind it. We uncover their stories in this excerpt from Wireframe issue 7, available now.

In 1998, the release of the Dreamcast gave Sega an opportunity to turn around its fortunes in the home console market. The firm’s earlier system, the Saturn, though host to some beloved titles, was running a distant third in sales behind the Nintendo 64 and PlayStation. The Dreamcast, by contrast, saw a successful launch and quickly became the go-to system for arcade-quality ports of fighting games, among other groundbreaking titles like Seaman and Crazy Taxi.

Unfortunately for fans, it wasn’t to last. The Dreamcast struggled to compete against the PlayStation 2, which launched in 2000, and at the end of March 2001, in the face of the imminent launch of the Nintendo GameCube and Microsoft’s new Xbox, Dreamcast left the stage, and Sega abandoned the console market altogether.

None of this stopped a vibrant homebrew development scene springing up around the console in Sega’s place, and even years later, the Dreamcast remains a thriving venue for indie developers. Roel van Mastbergen codes for Senile Team, the developers of Intrepid Izzy, a puzzle platformer coming soon to the PC, PS4, and Dreamcast.

Of the port to Sega’s ageing console, van Mastbergen tells us, “I started this project with only the PC in mind. I’m more used to developing for older hardware, though, so I tend to write code with low CPU and RAM requirements by force of habit. At some point I decided to see if I could get it running on the Dreamcast, and I was happy to find that it ran almost perfectly on the first try.”

It runs at a lower resolution than on PC, but Intrepid Izzy still maintains a smooth 60fps on Dreamcast.

One of the pluses of the Dreamcast, van Mastbergen points out, is how easy it is to develop for. “There are free tools and sufficient documentation available, and you can run your own code on a standard Dreamcast without any hardware modifications or hacks.”

Games burned to CD will play in most models of unmodified Dreamcast, usually with no extra software required. While this doesn’t result in a huge market — the customer base for new Dreamcast games is difficult to measure but certainly small — it makes development for original hardware far more viable than on other systems, which often need expensive and difficult-to-install modchips.

Many of the games now being developed for the system are available as digital downloads, but the state of Dreamcast emulation lags behind that of its competitors, with no equivalent to the popular Dolphin and PCSX2 emulators for GameCube and PS2. All this makes boxed games on discs more viable than on other systems — and, in many cases, physical games can also become prized collectors’ items.

Intrepid Izzy is developed with a custom code library that works across multiple systems; it’s simple to downscale PC assets and export a Dreamcast binary.

Kickstarting dreams

By now, you might be asking yourself what the point of developing for these old systems is — especially when creating games for PC is a much easier and potentially more profitable route to take. When it comes to crowdfunding, though, catering to a niche but dedicated audience can pay dividends.

Belgian developer Alice Team, creators of Alice Dreams Tournament, asked for €8000 in funding to complete its Dreamcast exclusive, which began development in 2006. It eventually raised €28,000 — more than treble its goal.

Intrepid Izzy didn’t quite reach such dizzying heights, only just meeting its €35,000 target, but van Mastbergen is clear it wouldn’t have been funded at all without the dedicated Dreamcast base. “The project has been under-funded since the beginning, which is slightly problematic,” van Mastbergen tells us. “Even so, it is true that the Dreamcast community is responsible for the lion’s share of the funding, which is a testament to how well-loved this system still is.”

You can read the rest of the feature in Wireframe issue 7, available in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us – worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

Face your fears in the indie horror, Someday You’ll Return.

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subscriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post Inside the Dreamcast homebrew scene | Wireframe issue 7 appeared first on Raspberry Pi.

Building a text adventure | Wireframe #6

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/making-text-adventure-wireframe-6/

Game developer Andrew Gillett explains how to make a simple text adventure in Python — and what pitfalls to avoid while doing so — in the latest issue of Wireframe magazine, out now.

Writing games in BASIC

The first game I ever wrote was named Pooh. It had nothing to do with the bear. In September 1982, I was four years old, and the ZX Spectrum home computer had just been released. It was incredible enough that the Spectrum let you play games on the TV, but like most home computers of the time, it also came with a built-in language called BASIC, and a manual which explained how to program it. In my first game, Pooh (the title was a misspelling), the player controlled a baby, represented by a pound sign, and had to guide it to a potty, represented by the letter O. There were no obstacles, no enemies, and if you tried to walk off the screen, the program would stop with an error message. I didn’t have any idea how to create a graphical game more complex than Pooh. I didn’t even know how to display a sprite on the screen.

The Hobbit, released in 1982, was widely praised for its intuitive parser.

Text adventures

Instead, I focused on writing text adventures, where the game describes scenes to the player (“You are in a comfortable, tunnel-like hall. You can see a door,” from 1982’s The Hobbit) and the player enters commands such as “Go through door” or “Kill goblin with sword.” Although this type of game is comparatively easy to write, I implemented it in the worst way possible. The code was essentially a huge list of IF statements. Each room had its own set of code, which would print out a description of the room and then check to see what the player typed. This ‘hard-coding’ led to the code being much longer than necessary, and more difficult to maintain.

The correct way would have been to separate my code and data. Each room would have had several pieces of data associated with it, such as an ID number, the description of the room (“You are in a small cave”), an array of objects which can be found in the room, and an array of room numbers indicating where the player should end up if they try to move in a particular direction – for example, the first number could indicate which room to go to if the player enters ‘NORTH’. You’d then have the main game code which keeps track of the room the player is currently in, and looks up the data for that room. With that data, it can then take the appropriate action based on the command the player typed.

Getting it right

The code below shows how to implement the beginnings of a text adventure game in Python. Instead of numeric IDs and arrays, the code uses string IDs and dictionary data structures, where each piece of data is associated with an ID or ‘key’. This is a more convenient option which wasn’t available in Spectrum BASIC. We first create a list of directions in which the player can potentially move. We then create the class Location which specifies each location’s properties. We store a name, a description, and a dictionary data structure which stores the other locations that the current location is linked to. For example, if you go north from the woods, you’ll reach the lake. The class includes a method named addLink, which adds entries to the linked locations dictionary after checking that the specified direction and destination exist.

Following the class definition, we then create a dictionary named locations. This has two entries, with the keys being woods and lake, and the values being instances of the Location class. Next, we call the addLink method on each of the locations we’ve just created, so that the player will be able to walk between them. The final step of the setup phase is to create the variable currentLocation, specifying where the player will start the game.

We then reach the main game loop, which will repeat indefinitely. We first display the description of the current location, along with the available directions in which the player can move. Then we wait for the player to input a command. In this version of the code, the only valid commands are directions: for example, type ‘north’ at the starting location to go to the lake. When a direction is entered, we check to make sure it’s a valid direction from the current location, then update currentLocation to the new location. When the main loop restarts, the description of the new location is displayed.

I moved on from the ZX Spectrum eight years after my dad first unpacked it. Despite the poor design of my code, I’d learned the essentials of programming. Ten years later, I was a game developer.

Further reading

If you’re keen to learn more about making a text adventure in Python, you could check out Phillip Johnson’s guide to the subject, Make Your Own Python Text Adventure. The author has also written a condensed version of the same guide.

You may also be interested in our free online course Object-oriented Programming in Python: Create Your Own Adventure Game.

More from Wireframe

You can discover more tutorials, alongside great reviews, articles and advice, in Wireframe issue 6, out now and available in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from the Raspberry Pi Press store — worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download the PDF for free.

The post Building a text adventure | Wireframe #6 appeared first on Raspberry Pi.

From Wireframe issue 5: Breakthrough Brits in conversation

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/wireframe-issue-5/

BAFTA-recognised developers Adrienne Law and Harry Nesbitt share their thoughts on making games, work-life balance, and more in this excerpt from Wireframe issue 5, available from today.

It’s certainly ‘woollies and scarf’ weather now, but the low-hanging sun provides a beautiful backdrop as Adrienne and Harry make their daily short walk from home to the ustwo games office. In late 2018, Adrienne Law and Harry Nesbitt were both recognised by BAFTA as Breakthrough Brits: an award given by BAFTA to new and emerging talent across a variety of art and entertainment industries. But that’s not the only thing they have in common — Adrienne and Harry work in the same office and are even housemates.

Monument Valley 2 screenshot

Monument Valley 2

Adrienne is a producer at ustwo games, most recently on the acclaimed puzzler Monument Valley 2. Harry doesn’t work for ustwo, but he’s a regular fixture there, taking a spare desk to work as the lead developer and artist for Alto’s Adventure and its sequel, Alto’s Odyssey.

Alto’s Odyssey screenshot

Alto’s Odyssey

As two professionals early in their careers in an ever-evolving industry, Adrienne and Harry find themselves with much in common, but the routes that led them to working and living together were very different. The pair agreed to take an hour out of their work schedules to speak to Wireframe, and to each other, about their personal experiences of game development, how it feels to release a game, work-life balance, and the potential of games to affect and enrich lives.

Adrienne Law: My route into the games industry was semi-accidental. I played games a lot when I was a kid but didn’t know there was an industry as such to go and work in. I did an English degree thinking that might possibly set me up for going into some kind of creative, story-driven field, which was what interested me. After that, I spent a few years working different jobs — I was a teaching assistant, I worked in finance, retail, marketing, and was circling around trying to get into film and TV industries.

Eventually, I got to the point where I went onto job sites and searched for “production assistant” and that’s where I found a production assistant role going at ustwo games. I thought, “Oh! Production is a thing in games! I didn’t know that.” I decided to just go for it. I ended up having a few interviews with ustwo — I think they were worried because I was quite quiet, and they weren’t sure how much I would step into the role — but they let me through the door and gave me a chance. I’ve been here ever since. I never set out to be in the games industry, but I think I’d been gaining a lot of skills and had an awareness of the medium, so those things combined into making me a good candidate for the role.

I went to an all girls’ school that specialised in maths and science, so there was no reason that I would have thought I couldn’t work in tech, but the school didn’t push the idea of working in tech and coding. I think if I had been aware of it from a younger age, I would have been a programmer.

Harry Nesbitt

Harry Nesbitt: I’ve always thought about working in games. From a young age, I had an interest in how games were made from an artistic standpoint. I would always look up who was responsible for the concept art. Concept art as a job was something I was aware of from a very young age.

Around 2006, when I started at university, indie games weren’t in the mainstream, and making games in your own bedroom wasn’t as popular an idea. When I discovered Unity, I thought “Oh, I can download this for free, and I can learn all the basics online.” I saw examples of illustrators who were downloading it and making cool, interesting little projects — almost like little art pieces — bringing their illustrations to life. It made me realise I could have a play with that. My knowledge of the basics of JavaScript and web development helped me pick up the coding side of things a little bit more easily.

When it came to making Alto’s Adventure, I knew a little bit of Unity and had been playing with it for about 12 months, so I realised I could at least be playing around with it, seeing what’s possible and using it as a way to demonstrate certain ideas.

Within a very short space of time, less than a week maybe, I’d been able to put together a basic prototype of the core systems, such as the terrain generation, basic player physics, even some effects such as particles and Alto’s scarf. It took another year and a half from there to get it finished, but online resources gave me what I needed to eventually get the game made. It’s not necessarily an experience I’d want to repeat though!

You can read the rest of this fantastic feature in Wireframe issue 5, out today, 17 January, in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us — worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

The cutest Wireframe cover to date!

Make sure to follow Wireframe on Twitter and Facebook for updates and exclusives, and for subscriptions, visit the Wireframe website to save 49% compared to newsstand pricing!

The post From Wireframe issue 5: Breakthrough Brits in conversation appeared first on Raspberry Pi.

From Wireframe issue 4: Recovering Destiny’s long-lost soundtrack

Post Syndicated from Ian Dransfield original https://www.raspberrypi.org/blog/wireframe-issue-4-destinys-long-lost-soundtrack/

Missing for five years, Destiny’s soundtrack album, Music of the Spheres, resurfaced in 2017. Composer Marty O’Donnell reflects on what happened, in this excerpt from Wireframe issue 4.

When Bungie unveiled its space-opera shooter Destiny in February 2013, it marked the end of two years of near silence from the creators of the Halo franchise. Fans celebrated at the prospect of an entirely new game from such well known talent. Behind closed doors, however, Destiny was in trouble.

Though the game was almost complete by mid-2013, plans to launch that September were put on hold when concerns over Destiny’s story forced its narrative structure to be rebuilt from scratch. It would be more than 18 months before Destiny was released: a fun but strange shooter that bore difficult-to-pin-down traces of its troubled gestation. But one element of Destiny – that had been a huge part of its development – was nowhere to be seen. It was an ambitious original soundtrack written and recorded with an impressive but unexpected collaborator: Paul McCartney.

Spherical music

Audio director and composer Marty O’Donnell had been with Bungie since the late 1990s, and for him, Destiny represented an opportunity to develop something new: a musical prequel to the video game. This would become Music of the Spheres – an eight-part musical suite that took nearly two years to complete. This was no mere soundtrack, however. Born out of discussions between O’Donnell and Bungie COO Pete Parsons early in the game’s production, it was to play an integral role in Destiny’s marketing campaign.

“I wasn’t writing this just to be marketing fodder,” O’Donnell laughs. “I was writing it as a standalone listening experience that would then eventually become marketing fodder – but I didn’t want the other to happen first.”

Between 2011 and 2012, Bungie and O’Donnell devised plans for the album.

“Every few weeks or so, I would be called to a meeting in one of their big conference rooms and there would be a whole bunch of new faces there, pitching some cool idea or other,” says O’Donnell. “[At one point] it was going to be a visualisation with your mobile device.”

Difference of opinion

But there were fundamental differences between what Bungie had planned and what Activision – Destiny’s publisher, and keeper of the purse strings – wanted.

“I think Activision was confused [about] why you would ever use music as marketing… And the other thing is, I honestly don’t think they understood why we were working with Paul McCartney. I think they didn’t think that that was the right person for the demographic.”

News of a collaboration with McCartney had raised eyebrows when he revealed his involvement on Twitter in July 2012. His interest had been piqued during his attendance at E3 2009 following the announcement of The Beatles: Rock Band, which was preceded by Bungie’s unveiling of Halo ODST.

Loop symphony

“I had a contact in Los Angeles who worked out deals with actors we used on Halo,” O’Donnell recalls. “He was able to make contact with Paul’s people and set up a meeting between the two of us in spring of 2011. My impression was that Paul saw a new crop of fans come from Beatles Rock Band and was interested in seeing what was involved with creating music for video games. He seemed convinced that Bungie was working on a project that he could get behind.”

Within a few weeks, O’Donnell and McCartney were exchanging ideas for Destiny.

“The first thing he sent me was what he called his ‘loop symphony’,” says O’Donnell. “He used the same looping tape recorder that he used on Sgt. Pepper’s and Revolver… He hauled this tape recorder out of his attic.”

Working with regular collaborator Michael Salvatori, O’Donnell and McCartney set about developing Music of the Spheres into a fully fledged album, comprising eight movements.

Priorities

“I have all of these wonderful things, which included interesting things he did on his guitar that sort of loop and sound otherworldly… I think there are a couple of times in The Path, which is the first piece, and then I think The Prison, which is the seventh piece, where we use a recording of Paul doing this loop with his voice. This little funny thing. That’s Paul’s voice, which is cool.”

The album was completed in December 2012 following recording sessions at Capitol Studios in California, Avatar Studios in New York, and Abbey Road in London. Musical elements from Music of the Spheres accompanied Bungie’s big reveal of Destiny at a PlayStation 4 event in New York in February 2013. But after that, things started to go south.

“After that PlayStation 4 announcement, I said, ‘Let’s figure out how to release this. I don’t care if we have Harmonix do an iPad version with a visualiser for it. I mean, if we can’t pull the trigger on something big and interesting like that, that’s fine with me. Let’s just release it online.’ It had nothing to do with making money… It was always fan service, in my mind at least.”

Activision, on the other hand, had other priorities. “Activision had a lot of say on the marketing. I think that’s where things started to go wrong, for me… things started being handled badly, or postponed, and then all of a sudden I was seeing bits of Music of the Spheres being cut up and presented in ways that I wasn’t happy with.”

You can read the rest of this fantastic feature in Wireframe issue four, out 20 December in Tesco, WHSmith, and all good independent UK newsagents.

Or you can buy Wireframe directly from us — worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you can also download a free PDF.

The post From Wireframe issue 4: Recovering Destiny’s long-lost soundtrack appeared first on Raspberry Pi.

Wireframe 3: Phoenix Point, modders going pro, and more

Post Syndicated from Ian Dransfield original https://www.raspberrypi.org/blog/wireframe-issue-3/

We said we’d be back with more, so here we are back with more: issue 3 of Wireframe, the magazine that lifts the lid on video games.

From the ashes

Our third issue sees the now-established mix of great features, guides, reviews, and plenty more beyond that. Headlining it all is our sit-down chat with Julian Gollop about his upcoming strategy title Phoenix Point, with the X-Com creator waxing lyrical about Rebelstar, Chaos, and the secret of great AI.

We also take a look at the careers of amateurs-turned-pros, checking out the modders who went legit and getting input from those who’ve made the jump from doing it for fun, to doing it for fun and money.

And it doesn’t stop there

We’re investigating Thrunt XL, the indie game made without typing a single line of code; Terry Cavanaugh tells us about his unconventional new rogue-like Dicey Dungeons; and veteran game developer Howard Scott Warshaw looks back on the making of his Atari 2600 classic, Yars’ Revenge.

Plus:

  • Make your own first-person shooter in Unity with our step-by-step guide
  • The fur flies in the forthcoming multiplayer shooter, Super Animal Royale
  • How parallax scrolling gives 2D games the illusion of depth
  • The platformer from El Salvador that survived an attack of the clones

All this, and a variety of news, previews, and reviews covering everything from triple-A releases to dinky, loveable indie games.

Buy Wireframe issue 3

Print copies of Wireframe are available now in WHSmith, Tesco, and all good independent UK newsagents. Or you can buy Wireframe directly from us — worldwide delivery is available. And if you’d like to own a handy digital version of the magazine, you have the option to also download a free PDF.

Subscription options!

Whether you want to sample six print issues for a bargain price, subscribe for a full year, or get a regular digital edition sent directly to your device, we have some superb deals for you to choose from! To find out how you can save up to 49% on Wireframe, head to wfmag.cc/subscribe.

Or you can get the digital edition directly to your smart device via our Android and iOS apps.

See you in a fortnight!

The post Wireframe 3: Phoenix Point, modders going pro, and more appeared first on Raspberry Pi.

Wireframe 2: The Blackout Club, Battlefield V anxiety, and more

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/wireframe-2/

Momentum firmly established, we’re back with our brilliant second issue of Wireframe — the magazine that lifts the lid on video games.

And yes, we are continuing to write ‘video games’ as two words.

Blacking out

In our sophomore edition, you’ll discover all manner of great features, guides, reviews, and everything else you could wish for. In an exclusive interview, BioShock 2 director Jordan Thomas talks about The Blackout Club, his new co-operative horror game – which also features on our fantastic front cover! With inspiration coming from the likes of Stranger Things, you just know The Blackout Club is going to be something special.

We also hear from Battlefield V’s Creative Director Lars Gustavsson in a candid discussion about his own personal excitement — and apprehension — surrounding the launch of DICE’s latest in its nearly 20-year-old series.

And a lot more

Is that all? Of course not. Thomas Was Alone and Subsurface Circular creator Mike Bithell shares his personal perspective on the ever-changing shape of video games.

Issue 2 also takes an extended look at an RPG’s journey from tabletop to screen: it’s not easy to bring the likes of Cyberpunk 2020 to the world of video games, and CD Projekt Red, Chris Avellone, and others tell us just why that is.

We’re just spoiling you now, but there’s plenty more besides, such as:

  • The maths behind matchmaking and video game economics
  • The changing face of Mega Man, an enduring 8-bit icon
  • An indie game’s path from Japanese restaurant to Nintendo eShop
  • The simple yet effective AI behind Galaxian’s angry aliens

All of this is joined by news, previews, and reviews of everything gaming has to offer.

Buy Wireframe issue 2

Physical copies of Wireframe are available now in WHSmith, Tesco, and all good independent UK newsagents. Of course, we don’t like to limit your choices, so you’re able to buy direct from us, with worldwide delivery available.

There’s also the option to download issue 2 a free PDF if you’d like a handy digital version.

Subscription options!

Fancy putting your feet up and letting Wireframe come directly to you? In that case, you should take a look at our subscription options: pick up a sample six issues for a bargain price, subscribe for a full year, or get the digital edition directly to your smart device via our Android and iOS apps. To find out how to save up to 49% on Wireframe’s print edition, head to wfmag.cc/subscribe.

wireframe magazine

See you again in two weeks!

A wild HackSpace magazine appeared

HackSpace magazine issue 13 is also out today, and it’s pretty sweet. Check it out here!

HackSpace issue 13 front cover

The post Wireframe 2: The Blackout Club, Battlefield V anxiety, and more appeared first on Raspberry Pi.

Wireframe issue 1 is out now!

Post Syndicated from Ryan Lambie original https://www.raspberrypi.org/blog/wireframe-issue-1/

Wireframe is our new twice-monthly magazine that lifts the lid on video games. In Wireframe, we look at how games are made, who makes them, and how you can make games of your own. And today, we’re releasing our very first issue!

Wireframe: the new magazine that lifts the lid on video games

Uploaded by Raspberry Pi on 2018-11-07.

The inaugural issue

In issue 1, Far Cry 4 director Alex Hutchinson talks to us about going indie. We look back at the British games industry’s turbulent early years; we explore how curves and probabilities shape the games we play; and we get hands-on with Nomada Studio’s forthcoming ethereal platformer, Gris.

Wireframe magazine

Plus:

  • Jessica Price on the state of game criticism
  • Portal squeezed onto the Commodore 64
  • Treasure — the iconic game studio at 25
  • Gone Home’s Kate Craig on indie game design workarounds
  • And much, much more…

About Wireframe magazine

Cutting through the hype, Wireframe takes a more indie-focused, left-field angle than traditional games magazines. As well as news, reviews, and previews, we bring you in-depth features that uncover the stories behind your favourite games.

Wireframe magazine

And on top of all that, we also help you create your own games! Our dedicated Toolbox section is packed with detailed tutorials and tips to guide you in your own game development projects.

wireframe issue 1 cover

Raspberry Pi is all about making computing accessible to everyone, and in Wireframe, we show you how programming, art, music, and design come together to make the video games you love to play — and how you can use these elements to build games yourself.

Free digital edition

We want everyone to enjoy Wireframe and learn more about creating video games, so from today, you’ll also be able to download a digital copy of issue 1 of Wireframe for free. Get all the features, guides, and lively opinion pieces of our paper-and-ink edition as a handy PDF from our website.

Wireframe in the wild

You can find the print edition of Wireframe issue 1 in select UK newsagents and supermarkets from today, priced at just £3. Subscribers also save money on the cover price, with an introductory offer of twelve issues for just £12.

For more information, and to find out how to order Wireframe from outside the UK, visit wfmag.cc.

The post Wireframe issue 1 is out now! appeared first on Raspberry Pi.

Wireframe: a new games magazine with a difference

Post Syndicated from Russell Barnes original https://www.raspberrypi.org/blog/wireframe-announcement/

We’re pleased to announce Wireframe: a new, £3, twice-monthly magazine that lifts the lid on video games.

Raspberry Pi is all about making computing accessible to everyone, and in Wireframe, we’ll show you how programming, art, music, and design come together to make the video games you love to play — and how you can use these elements to create games yourself.

Read on to find out how you can get a FREE physical copy of the first issue!

Wireframe magazine

Wireframe magazine — launching on 8 November

Cutting through the hype, Wireframe will have a more indie-focused, left-field angle than traditional games magazines. As well as news, reviews, and previews, we’ll have in-depth features that uncover the stories behind your favourite games, showing you how video games are made, and who makes them.

On top of all that, we’ll also help you discover how you can make games of your own. Our dedicated Toolbox section will be packed with detailed guides and tips to help you with your own game development projects.

Early-access offer: get a free copy of issue 1

Because we’re so excited about our new magazine, we’re offering you a free copy of Wireframe’s first issue! Simply sign up on our website before the 8 November (or while stocks last) to get yours.

Wireframe magazine

Click here to order your free copy of issue 1!

Each early-access edition of Wireframe will contain a rather tempting discount subscription offer, and will arrive around the time of launch (overseas deliveries may take longer, and may incur a small postage charge). Don’t hang around! Stocks are limited and once they’re gone, they’re gone.

Free digital edition

We want everyone to enjoy Wireframe and learn more about their favourite hobby, so you’ll be able to download a digital version of all issues of Wireframe for free. Get all the features, guides, and lively opinions of our first-ever paper-and-ink edition as a handy PDF from our website from 8 November.

Wireframe in the wild

You’ll find the print edition of Wireframe in select UK newsagents from 8 November, priced at just £3. Subscribers will save money on the cover price, with an introductory offer of 12 issues for just £12 launching at the same time as the magazine. For more information, and terms and conditions, transport yourself to the Wireframe website at wfmag.cc!

The post Wireframe: a new games magazine with a difference appeared first on Raspberry Pi.