Tag Archives: wireframe

Who remembers E.T. for the Atari 2600?

via Raspberry Pi

In the latest issue of Wireframe magazine, video game pioneer Howard Scott Warshaw reflects on the calamitous E.T. for the Atari 2600. Could it serve as a useful metaphor for real life?

When Julius Caesar ran into Brutus on the Ides of March so many years ago, it changed his life dramatically. I would say the same thing about my life when I ran into the E.T. project, though in my case, the change wasn’t quite so abrupt… or pointed. People say that my E.T. game was ahead of its time, so much so that it didn’t work for many players in its time. Fair enough. But E.T. is more than that. On many levels, that game has served as a metaphor for life, at least for my life. Let me explain, and perhaps it will sound familiar in yours as well.

ET for Atari

There was an aura of promise and anticipation on the advent of the E.T. project – much like the prospect of graduating from college and entering the working world as a computer programming professional. This was super-exciting to me. Once I began the challenge of delivering this game, however, the bloom left the rose (no matter how many times I healed it). Similarly, on my entry into the working world, my excitement was quashed by the unsatisfying nature and demands of typical corporate computing tasks. This is analogous to the experience of E.T. players, having just unwrapped the game. They pop the cartridge in, fire it up, and venture forward with innocent exuberance… only to be crushed by a confusing and unforgiving game world. Perhaps the E.T. game was some sort of unconscious impulse on my part. Was I recreating the disappointment of my first foray into corporate life? Highly unlikely, but the therapist in me just had to ask.

In the E.T. game, I spend a lot of time wandering around and falling into pits. Sometimes I find treasure in those pits. Sometimes I’m just stuck in a pit and I need to dig my way out. That costs energy I could have used on more productive endeavours. There’s also a power-up in the game you can use to find out if there is something worth diving in for. Sadly, there’s no such power-up in life. Figuring out the difference between the treasure and the waste has always been one of my biggest questions, and it’s rarely obvious to me.

ET for Atari

One of the treasures you find in the game is the flower. The act of healing it brings benefits and occasional delightful surprises. I was at the bottom of a ‘pit’ in my life when I found the path to becoming a psychotherapist (another act of healing). It helped me climb out and take some big steps toward winning the bigger game.

E.T. is all about the pits, at least it seems so for many who talk about it. And they do so with such derision. Many times I’ve heard the phrase, “E.T. isn’t about the pits. It is the pits!” But are pits really so bad? After all, there are situations in which being stuck in a pit can be an advantage – OK, perhaps not so much in the game. But in life, I find it’s unwise to judge where I am until I see where it takes me. There have been times where major disappointments ended up saving me from a far worse fate had I been granted my original desire. And in more concrete terms, during a hurricane or tornado, there are far worse outcomes than stumbling into a pit. Sometimes when I trip and fall, I wind up dodging a bullet.

ET for Atari

Yes, in the game you can wind up wandering aimlessly around, feeling hopeless and without direction (somehow, they didn’t put that on the box). But ultimately, if you persevere (and read the directions), you can create a reasonably satisfying win. After finishing development of the game, there was a long period of waiting before any feedback arrived. Then it came with a vengeance. Of course, that only lasted for decades. My life after Atari seemed a bit of a wasteland for a long time too. Rays of sunlight broke through on occasion, but mostly cloudy skies persisted. Things didn’t improve until I broke free from the world in which I was stuck in order to launch the improbable life I truly wanted.

ET for Atari

But it’s not like there were no lingering issues from my E.T. experience. It turns out that ever since the E.T. project, I have a much greater propensity to procrastinate, regularly shorting myself of dev time. I didn’t used to do that before E.T., but I’ve done it quite a bit since. I delay launching a genuine effort, then rush into things and try to do them too quickly. This results in a flurry of motion that doesn’t quite realise the potential of the original concept. More flailing and more failing. It doesn’t mean my idea was poor; it means it was unrefined and didn’t receive sufficient nourishment. On reflection, I see there are both challenges and opportunities at every turn. Pits and treasures. Which of those I emphasise as I move forward is how I construct the life I’m going to have, and I’m doing that all the time.

ET for Atari

Pits and treasures, this is much of life. My E.T. game has mostly pits. Truth be known, people like to call them ‘pits’, but I’ve always thought of them as wells: a place to hide, to take repose and to weather out life’s storms. For me, that has been the value of having so many wells. I hope it works for you as well. Try it on. It just might fit like Caesar’s toga. And if it doesn’t, you can say what Brutus said on that fateful day: “At least I took a stab at it.”

Get your copy of Wireframe issue 55

You can read more features like this one in Wireframe issue 54, available directly from Raspberry Pi Press — we deliver worldwide.

wireframe 54 cover

And if you’d like a handy digital version of the magazine, you can also download issue 54 for free in PDF format.

The post Who remembers E.T. for the Atari 2600? appeared first on Raspberry Pi.

Code a Spectrum-style Crazy Golf game | Wireframe #54

via Raspberry Pi

Putt the ball around irrational obstacles in our retro take on golf. Mark Vanstone has the code

First released by Mr. Micro in 1983 – then under the banner of Sinclair Research – Krazy Golf was, confusingly, also called Crazy Golf. The loading screen featured the Krazy spelling, but on the cover, it was plain old Crazy Golf.

Designed for the ZX Spectrum, the game provided nine holes and a variety of obstacles to putt the ball around. Crazy Golf was released at a time when dozens of other games were hitting the Spectrum market, and although it was released under the Sinclair name and reviewed in magazines such as Crash, it didn’t make much impact. The game itself employed a fairly rudimentary control system, whereby the player selects the angle of the shot at the top left of the screen, sets the range via a bar along the top, and then presses the RETURN key to take the shot.

The game was called Crazy Golf on the cover, but weirdly, the loading screen spelled the name as Krazy Golf. The early games industry was strange.

If you’ve been following our Source Code articles each month, you will have seen the pinball game where a ball bounces off various surfaces. In that example, we used a few shortcuts to approximate the bounce angles. Here, we’re only going to have horizontal and vertical walls, so we can use some fairly straightforward maths to calculate more precisely the new angle as the ball bounces off a surface. In the original game, the ball was limited to only 16 angles, and the ball moved at the same speed regardless of the strength of the shot. We’re going to improve on this a bit so that there’s more flexibility around the shot angle; we’ll also get the ball to start moving fast and then reduce its speed until it stops.

Horizontal or vertical obstruction?

To make this work, we need to have a way of defining whether an obstruction is horizontal or vertical, as the calculation is different for each. We’ll have a background graphic showing the course and obstacles, but we’ll also need another map to check our collisions. We need to make a collision map that just has the obstacles on it, so we need a white background; mark all the horizontal surfaces red and all the vertical surfaces blue.

As we move the ball around the screen (in much the same way as our pinball game) we check to see if it has collided with a surface by sampling the colours of the pixels from the collision map. If the pixel’s blue, we know that the ball has hit a vertical wall; if it’s red, the wall’s horizontal. We then calculate the new angle for the ball. If we mark the hole as black, then we can also test for collision with that – if the ball’s in the hole, the game ends.

The pointer’s angle is rotated using degrees, but we’ll use radians for our ball direction as it will simplify our movement and bounce calculations.

Get the code

We have our ball bouncing mechanism, so now we need our user interaction system. We’ll use the left and right arrow keys to rotate our pointer, which designates the direction of the next shot. We also need a range-setting gizmo, which will be shown as a bar at the top of the screen. We can make that grow and shrink with the up and down arrows.

Then when we press the RETURN key, we transfer the pointer angle and the range to the ball and watch it go. We ought to count each shot so that we can display a tally to the player once they’ve putted the ball into the hole. From this point, it’s a simple task to create another eight holes – and then you’ll have a full crazy golf game!

Here’s Mark’s code for a simple golf game. To get it running on your system, you’ll need to install Pygame Zero. And for the full code, head to our Github.

Get your copy of Wireframe issue 55

You can read more features like this one in Wireframe issue 54, available directly from Raspberry Pi Press — we deliver worldwide.

And if you’d like a handy digital version of the magazine, you can also download issue 54 for free in PDF format.

The post Code a Spectrum-style Crazy Golf game | Wireframe #54 appeared first on Raspberry Pi.

Code your own pinball game | Wireframe #53

via Raspberry Pi

Get flappers flapping and balls bouncing off bumpers. Mark Vanstone has the code in the new issue of Wireframe magazine, available now.

There are so many pinball video games that it’s become a genre in its own right. For the few of you who haven’t encountered pinball for some reason, it originated as an analogue arcade machine where a metal ball would be fired onto a sloping play area and bounce between obstacles. The player operates a pair of flippers by pressing buttons on each side of the machine, which will in turn ping the ball back up the play area to hit obstacles and earn points. The game ends when the ball falls through the exit at the bottom of the play area.

NES Pinball
One of the earliest pinball video games – it’s the imaginatively-named Pinball on the NES.

Recreating pinball machines for video games

Video game developers soon started trying to recreate pinball, first with fairly rudimentary graphics and physics, but with increasingly greater realism over time – if you look at Nintendo’s Pinball from 1984, then, say, Devil’s Crush on the Sega Mega Drive in 1990, and then 1992’s Pinball Dreams on PC, you can see how radically the genre evolved in just a few years. In this month’s Source Code, we’re going to put together a very simple rendition of pinball in Pygame Zero. We’re not going to use any complicated maths or physics systems, just a little algebra and trigonometry.

Let’s start with our background. We need an image which has barriers around the outside for the ball to bounce off, and a gap at the bottom for the ball to fall through. We also want some obstacles in the play area and an entrance at the side for the ball to enter when it’s first fired. In this case, we’re going to use our background as a collision map, too, so we need to design it so that all the areas that the ball can move in are black.

Pinball in Python
Here it is: your own pinball game in less than 100 lines of code.

Next, we need some flippers. These are defined as Actors with a pivot anchor position set near the larger end, and are positioned near the bottom of the play area. We detect left and right key presses and rotate the angle of the flippers by 20 degrees within a range of -30 to +30 degrees. If no key is pressed, then the flipper drops back down. With these elements in place, we have our play area and an ability for the player to defend the exit.

All we need now is a ball to go bouncing around the obstacles we’ve made. Defining the ball as an Actor, we can add a direction and a speed parameter to it. With these values set, the ball can be moved using a bit of trigonometry. Our new x-coordinate will move by the sin of the ball direction multiplied by the speed, and the new y-coordinate will move by the cos of the ball direction multiplied by speed. We need to detect collisions with objects and obstacles, so we sample four pixels around the ball to see if it’s hit anything solid. If it has, we need to make the ball bounce.

Get the code

Here’s Mark’s pinball code. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.

If you wanted more realistic physics, you’d calculate the reflection angle from the surface which has been hit, but in this case, we’re going to use a shortcut which will produce a rough approximation. We work out what direction the ball is travelling in and then rotate either left or right by a quarter of a turn until the ball no longer collides with a wall. We could finesse this calculation further to create a more accurate effect, but we’ll keep it simple for this sample. Finally, we need to add some gravity. As the play area is tilted downwards, we need to increase the ball speed as it travels down and decrease it as it travels up.

All of this should give you the bare bones of a pinball game. There’s lots more you could add to increase the realism, but we’ll leave you to discover the joys of normal vectors and dot products…

Get your copy of Wireframe issue 53

You can read more features like this one in Wireframe issue 53, available directly from Raspberry Pi Press — we deliver worldwide.

And if you’d like a handy digital version of the magazine, you can also download issue 53 for free in PDF format.

The post Code your own pinball game | Wireframe #53 appeared first on Raspberry Pi.

Recreate Gradius’ rock-spewing volcanoes | Wireframe #52

via Raspberry Pi

Code an homage to Konami’s classic shoot-’em-up, Gradius. Mark Vanstone has the code in the new edition of Wireframe magazine, available now.

Released by Konami in 1985, Gradius – also known as Nemesis outside Japan – brought a new breed of power-up system to arcades. One of the keys to its success was the way the player could customise their Vic Viper fighter craft by gathering capsules, which could then be ‘spent’ on weapons, speed-ups, and shields from a bar at the bottom of the screen.

Gradius screenshot
The Gradius volcanoes spew rocks at the player just before the end-of-level boss ship arrives.

Flying rocks

A seminal side-scrolling shooter, Gradius was particularly striking thanks to the variety of its levels: a wide range of hazards were thrown at the player, including waves of aliens, natural phenomena, and boss ships with engine cores that had to be destroyed in order to progress. One of the first stage’s biggest obstacles was a pair of volcanoes that spewed deadly rocks into the air: the rocks could be shot for extra points or just avoided to get through to the next section. In this month’s Source Code, we’re going to have a look at how to recreate the volcano-style flying rock obstacle from the game.

Our sample uses Pygame Zero and the randint function from the random module to provide the variations of trajectory that we need our rocks to have. We’ll need an actor created for our spaceship and a list to hold our rock Actors. We can also make a bullet Actor so we can make the ship fire lasers and shoot the rocks. We build up the scene in layers in our draw() function with a star-speckled background, then our rocks, followed by the foreground of volcanoes, and finally the spaceship and bullets.

Dodge and shoot the rocks in our homage to the classic Gradius.

Get the ship moving

In the update() function, we need to handle moving the ship around with the cursor keys. We can use a limit() function to make sure it doesn’t go off the screen, and the SPACE bar to trigger the bullet to be fired. After that, we need to update our rocks. At the start of the game our list of rocks will be empty, so we’ll get a random number generated, and if the number is 1, we make a new rock and add it to the list. If we have more than 100 rocks in our list, some of them will have moved off the screen, so we may as well reuse them instead of making more new rocks. During each update cycle, we’ll need to run through our list of rocks and update their position. When we make a rock, we give it a speed and direction, then when it’s updated, we move the rock upwards by its speed and then reduce the speed by 0.2. This will make it fly into the air, slow down, and then fall to the ground. 

Collision detection

From this code, we can make rocks appear just behind both of the volcanoes, and they’ll fly in a random direction upwards at a random speed. We can increase or decrease the number of rocks flying about by changing the random numbers that spawn them. We should be able to fly in and out of the rocks, but we could add some collision detection to check whether the rocks hit the ship – we may also want to destroy the ship if it’s hit by a rock. In our sample, we have an alternative, ‘shielded’ state to indicate that a collision has occurred. We can also check for collisions with the bullets: if a collision’s detected, we can make the rock and the bullet disappear by moving them off-screen, at which point they’re ready to be reused.

That’s about it for this month’s sample, but there are many more elements from the original game that you could add yourself: extra weapons, more enemies, or even an area boss.

Here’s Mark’s volcanic code. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.

Get your copy of Wireframe issue 52

You can read more features like this one in Wireframe issue 52, available directly from Raspberry Pi Press — we deliver worldwide.

Wireframe issue 52's cover

And if you’d like a handy digital version of the magazine, you can also download issue 52 for free in PDF format.

The post Recreate Gradius’ rock-spewing volcanoes | Wireframe #52 appeared first on Raspberry Pi.

Meet Katt Strike: Musician, producer, and Twitch streamer

via Raspberry Pi

Musician, producer, and Twitch star Katt Strike chats to Wireframe magazine about video games, toxicity online and the appeal of streaming.

What’s your favourite game?

Oh, that’s a very hard question! I’d have to narrow it down between Fallout: New Vegas and The Legend of Zelda: Majora’s Mask.

katt strike streaming on twitch
Katt in action with Blootrix and friends

And why is that? What is it about those particular games that resonates so much with you?

For me, it’s all about immersion, fun, and humour. I can get lost in both of those games for hours on end; they still entertain me greatly (plus, they’re both amazing games, to boot). Fallout: New Vegas is quite leftfield at times. There are many moments you’d never expect, plus the dialogue is hilarious throughout. 

Which game was it that got you into gaming to begin with? What are your enduring memories of it?

My parents were both gamers, so I started out around the age of four with Street Fighter 2 (on the Sega Saturn). It wasn’t until Crash Bandicoot that I really started to enjoy games; we would spend hours playing it with my mum as she angrily tried to get every gem on every level, frequently calling Crash a “wee b*****d”.

Has there ever been a point you’ve been put off gaming? If so, why?

To be honest, not really. For years, gaming was a very solitary thing to me, an escape. It’s such a huge part of my life that I couldn’t imagine not playing them. If I ever encounter toxicity online, I block and move on. I play games every day, and I could never imagine not having that in my life. 

What’s the appeal of playing games for an audience – whether that’s pre-recorded or livestreaming?

I think there’s a lot of reasons streaming appeals to me. Personally, I enjoy sharing games with people, and I’ve learned a lot about the games I play whilst streaming them (such as secrets, techniques, and facts). As someone with a chronic illness, I’ve struggled to make new friends because I was unable to work/go out for a long time – Twitch allowed me to connect with people very similar to me. There’s something electric about a good stream, when you have a brilliant back and forth with the chat and the game you’re playing is good; it’s exciting. 

Originally, I just wanted to play games and make friends, but now it fuels my ambition and creativity. I have a very supportive community, and they keep me coming back and wanting to improve. 

Katt strike with long pink hair and black hat

You can watch Katt Strike streaming through the week over on Twitch: wfmag.cc/Striker

Katt is also on Twitter, Instagram, YouTube, and SoundCloud so, no excuses!

The post Meet Katt Strike: Musician, producer, and Twitch streamer appeared first on Raspberry Pi.

Recreate Exerion’s pseudo-3D landscape | Wireframe #51

via Raspberry Pi

Swoop over mountains in our homage to Jaleco’s shooter. Mark Vanstone has the code in the latest issue of Wireframe magazine, out now.

Taking the shooting action of Galaxian from a few years earlier, Japanese developer Jaleco released Exerion in 1983. What helped Exerion stand out from other shoot-’em-ups of the period, though, was its pseudo-3D background, which used both a scrolling landscape and moving background elements to create the illusion of depth. This was quite an achievement considering the hardware of the day, and it’s still an eye-catching effect even now.

Exerion’s pseudo-3D effect helped the game stand out from the crowd of other shooters packed into arcades at the time.

Three main elements

To recreate Exerion’s scrolling in Pygame Zero, we need to break the effect down into three main elements. The first is the scrolling stripes that form the landscape’s base layer. These are followed by the elements that roll over the landscape as it scrolls down the screen. Then thirdly, there’s the player’s movement, which affects both the other two elements. Let’s start with the scrolling landscape, which is made of alternating coloured stripes. To give the sense of perspective, they start very thin on the horizon and, as they move down the screen, they grow in thickness. We can create this with a list that contains the heights of each stripe, increasing as we go through the list. Then in our draw() function, we run through the list, drawing the stripes downwards from the horizon using the heights in our list. Then we increase the height of each stripe. When the first stripe reaches a certain height, we take the last one off the end of the list and add it to the beginning, resetting its height to the smallest. 

Our homage to Exerion. You can’t tell from a static image, but the illusion of depth is amazing. Honest. 

Landscape details

The next items to code are the landscape details. These are buildings and hills that we want to move with the stripes so that it looks as though the player’s flying over them as they scroll by. We need to do this in two sections as some will be drawn behind the stripes as they’re over the horizon, while others will be in front of the stripes. We’ll give each landscape item an index which ties it to a stripe, but we’ll give items that are beyond the horizon negative indexes, and those in front, positive.

All the landscape items will start with a negative index to indicate that they all start beyond the horizon. So in the draw() function, we have an initial loop to draw all the items behind the horizon, and then while we’re drawing the stripes, we also draw the items which have the same index as the stripes, so they appear in front. Once we have these two parts, we’ll have a continuous carousel of stripes and landscape items.

Player aircraft

Now we need the player aircraft. We can move it around using the arrow keys, but we want to have the background graphics moving to give the impression of a 3D landscape: if the player moves upwards, we move the horizon down, and do the opposite if the player moves downwards. We then apply a parallax effect to the landscape items. The way we do this is by moving the items at the back a small amount in the opposite direction from the player’s movement, and as we work down through the items, they move more and more. This enhances the impression of depth. 

Once we’ve added a tilt to the aircraft as it turns, we have the makings of an Exerion clone. All that needs to be added are the aliens to shoot at – if you want to add these, then you could take the Galaxian routine from last month’s Source Code. 

Here’s Mark’s code for an Exerion-style, pseudo-3D background. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.

Get your copy of Wireframe issue 51

You can read more features like this one in Wireframe issue 51, available directly from Raspberry Pi Press — we deliver worldwide.

And if you’d like a handy digital version of the magazine, you can also download issue 51 for free in PDF format.

The post Recreate Exerion’s pseudo-3D landscape | Wireframe #51 appeared first on Raspberry Pi.