Connexion
At the Raspberry Pi Foundation, we believe that learning to program equips young people with the knowledge and skills they need to thrive in an increasingly digital world. For many educators, teaching programming effectively can be challenging, particularly when their learners are at different stages in their programming journey. Ask learners to write code too early, and they might struggle or feel intimidated. Rely too heavily on step-by-step instructions, and you limit learners’ chances to explore ideas or develop deeper understanding.
The PRIMM framework — Predict, Run, Investigate, Modify, Make — provides educators with a structure for teaching programming. This research-informed teaching approach balances support with independence and helps learners build their understanding before they write their own code, whatever their starting point.
To help educators use this approach confidently, we have launched a new short online course, Using PRIMM to teach programming, which is available on our new Training Hub platform for free.
This practical, self-paced course gives educators the knowledge they need to use the PRIMM approach to design and adapt programming activities to suit their learners.
The course takes 1–2 hours to complete, and we have designed it for educators working in formal or non-formal learning environments around the world, using any block-based or text-based programming language. All you need is some experience of creating and adapting simple programs.
The course starts with considering the five stages of PRIMM, when and why to use each stage, and how they work together to support learning. It covers how PRIMM aligns with key teaching principles such as scaffolding, managing cognitive load, and progression, and examines how the approach supports formative assessment by making learners’ thinking — and any misunderstandings — more visible.
Although pedagogy forms the core of this course, we have deliberately avoided a theory-heavy approach. Instead, the course is designed to help you learn through hands-on activities. By reflecting, taking part in discussions with other computing educators, and completing practical tasks, you will explore how PRIMM works in real teaching contexts.
After an introduction to the core ideas of PRIMM, you will design a new programming activity, or adapt an existing one, using the PRIMM structure. This will support you to think carefully about what your learners know and can do, likely misconceptions, and how each stage of PRIMM can be used effectively, including when your learners have varied learning needs and levels of programming experience.
With its emphasis on activity design, the course will support you to develop resources you can use and keep adapting in your own setting. By the end, you will have a complete PRIMM activity designed specifically for your learners, and a clear sense of how to teach programming in a structured and supportive way.
Using PRIMM to teach programming is available on our new Training Hub, where we offer all our professional development courses for free. The Training Hub offers flexible, reflective learning experiences across a range of topics, helping you build your subject knowledge and bring research-informed teaching approaches into your day-to-day practice.
Whether you are an experienced computing teacher, a volunteer educator, or a parent looking to support their child’s learning, we invite you to join us there.
The post ‘Using PRIMM to teach programming’: A new short course for educators appeared first on Raspberry Pi Foundation.
In the age of AI, we believe kids still need to learn to code. We’re also testing how AI tools can be used to help with teaching and learning programming. This blog dives into our new classroom unit ‘Programming with AI’, which we’ve developed for teachers to introduce students to learning to code using tools built on large language models (LLMs). We share an overview of the unit, and the early excitement of educators and learners with whom we’re exploring this new approach to teaching and learning programming.
As India is accelerating its efforts to modernise digital and computing education, it’s the ideal place for us to test how best to introduce learners to AI-assisted approaches to programming and teach them responsible AI use.
We decided to design a ‘Programming with AI’ unit of eight lessons that support students aged 14–16 to progress from block-based programming to text-based Python programming, Python being one of the most widely employed programming languages in industry and academia. In the new unit, students are guided to use LLM-based tools safely, ethically, and responsibly in order to undertake data analysis projects in Python. Students learn how to use the tools, such as Gemini and ChatGPT, to deepen their understanding, experiment with ideas, and connect classroom concepts with real-world technological applications.
The ‘Programming with AI’ unit is currently being piloted across five residential schools under our partner, the Telangana Social Welfare Residential Educational Institutions Society. In the coming months, we will evaluate the impact of this AI-supported approach to learning programming on student engagement, motivation, and overall learning outcomes.
During the design phase of the unit, we identified three main challenges we wanted to address:
To solve the first problem, we decided that the initial lessons in the unit should start by showing familiar Scratch blocks right next to the equivalent Python syntax. This direct comparison makes the transition from block-based to text-based programmer smoother.
To teach prompting, we built a gradual path. The unit starts with a debugging code activity, where students get code with errors and a prompt to make an LLM tool fix the errors. Later, they learn to break down a prompt into their goal (what output they want) and the context (additional information for the LLM tool). Eventually, they use a structured framework to prompt the tool to generate complete, bug-free code.
Handling the unpredictable outputs of LLM tools we turned into a learning activity. In one lesson, students are given different chatbot-generated code segments and asked to analyse and reflect on the code quality. This crucial exercise helps them build the critical thinking and code evaluation skills they need for programming with AI tools.
Over the eight lessons, there is a progression of Python concepts and generative AI concepts, as shown in the image above. They lead students to complete two challenging, real-world data analysis projects.
To ensure the successful pilot of the ‘Programming with AI’ unit, a comprehensive teacher training program was essential. We understood that teachers needed confidence and competence not only in the subject matter — programming — but also in guiding students to ethically and effectively use LLM tools.
The training was an intensive, three-day programme: two days were held in-person for deep collaboration and one day was virtual for reinforcing key information. We covered five critical areas:
This training ensured our educators were not just teaching a new unit, but felt like confident facilitators ready to lead the shift towards AI-supported learning.
The pilot of the ‘Programming with AI’ unit began during the second week of December 2025 across five selected schools. It was immediately met with enthusiastic student engagement — they were highly excited to learn Python programming using LLM tools.
When teachers initiated discussions about AI, students demonstrated their familiarity with LLMs, chatbots, and related concepts. They were not only aware of generative AI but could readily name and describe the functions of LLM tools, telling us they were actively using these tools to create projects in various other subjects.
Students could easily connect with the activities in the lessons as they had foundational understanding of programming, which they developed while learning block-based coding in Scratch. This prior knowledge enabled their seamless transition to the new learning. Perhaps most impressive was the students’ rapid adoption of LLM tools to debug their code. This skill can ease what is traditionally a steep learning curve when students first learn text-based programming.
We are now eagerly anticipating their curiosity and progress in the upcoming lessons.
With the initial enthusiasm confirmed, the pilot program moves into its next critical phase. Teachers will continue to deliver the unit over the next few months in the five selected schools in Telangana.
During this extended observation period, our primary focus will be on rigorous data collection and impact assessment. We will closely monitor how students interact with the provided learning materials and how they use LLM tools throughout the unit. We will systematically assess whether the new teaching approach successfully helps students achieve the defined learning objectives for Python programming. Crucially, we will capture comprehensive data to understand the impact of this AI-integrated approach on engagement, skill acquisition, and problem-solving compared to traditional methods.
Based on the synthesis and analysis of all the gathered data, we will share our gathered insights early next year. The findings will inform our plans for more widely introducing the AI-integrated unit and for developing similar content for other settings and age groups.
The post Introducing our new ‘Programming with AI’ unit appeared first on Raspberry Pi Foundation.
It’s been over a year since I last wrote an update on this blog about our research and as we’ve just published our 2025 Annual Report, this is an ideal opportunity to share what we’ve been working on at the Raspberry Pi Computing Education Research Centre.
We are a research centre based in the Department of Computer Science and Technology at the University of Cambridge, with a team that spans the university and the Raspberry Pi Foundation. We conduct research into many aspects of the teaching and learning of computing and AI and we work closely with schools, teachers and young people to ensure our research is applicable to practice.
Below I highlight some of the projects we’ve worked on in the academic year 2024-2025:
As I’ve written on this blog before, computing education is a global challenge. In one of the Research Centre’s projects, we are looking at how computing education is spreading around the world.
We found that between 2019 and 2024 the number of countries offering computing education had doubled, and that two thirds of all countries now offer, or have concrete plans to offer, computing education. This research has already been highlighted in the Stanford AI Index, and we are considering repeating the analysis in future years in order to have the most accurate and up-to-date information displayed in our map.
We have a number of projects in the area of AI education.
We are very interested in how to teach about AI, and held a workshop with teachers who were interested in the teaching of AI in February. Following on from the workshop results, we are interviewing more stakeholders, including UK-based experts, teachers and students, about their perspectives on concepts and skills that should be taught as part of an AI curriculum.
We’re also researching data science and data ethics education, which are foundational aspects of AI literacy. Most of the current AI systems are data-driven, having been trained on vast amounts of data. Therefore students need to understand about data and data science if they are to learn about AI systems. Therefore we’ve conducted two detailed literature reviews on data science and on data ethics this year. The first of these will be published in March at the WiPSCE conference.
One of our PhD students, Salomey Addo, has been examining how AI is taught in Ghana, where it is part of the curriculum for young people between ages 12 and 15. This year Salomey published a paper reporting that Ghanaian teachers have positive attitudes towards teaching AI but feel unprepared for it. She’s also developed unplugged resources to teach about artificial neural networks (ANNs).
ANNs are a fundamental technology used in a variety of AI systems, including image recognition and language translation systems. While ANNs are included in the Ghanaian AI curriculum, Salomey observed that teachers had difficulty with this particular topic The resources she developed are directly inspired by this, and involved teaching through role play and a board game.
This is an area we’ve also done some research in in the past year.
Carrie Anne Philbin published a paper in September showing that — at least in higher education — much of the use of generative AI in computing education is just duplicating the way teachers might already teach, and is primarily passive from a students’ perspective.
Meanwhile Katharine Childs and Veronica Cucuiat have been looking at how large language models (LLMs) can support secondary school programming education by helping students understand programming error messages.
Text-based programming is a topic featured in many computing curricula around the world. Teachers and researchers know that younger learners, for example at the lower secondary school level, can find debugging text-based programs very challenging. Although we’ve seen decades of research around programming and debugging focusing on learners who are in higher education, very little research has been done with school-age students.
In his research, Laurie Gale, a final-year PhD student at the Research Centre, found that learners were impatient to fix programs by trial and error, without figuring out what the real problemwas with their code or the underlying algorithm. He subsequently developed a tool called PRIMM Debug, which supports a more reflective and systematic approach to debugging. This tool enables learners to slow down when they are programming and to be more reflective. You can read more about it on the Research Centre website, and also catch up on the Foundation research seminar where he presented his work.
As part of a 5-year longitudinal project, running across the whole UK and the first project of its kind, we are looking at how physical computing impacts primary and secondary school learners. We’re investigating the effect of physical computing on learners’ creativity, agency and confidence, over time and at particular points known to be important for their subject choices. We are working with a wonderful set of partner primary schools who we visit each year.
This year we reported some of our first results, which point to teachers’ perceptions of physical computing being engaging and inclusive for primary-aged children. Starting next spring, we will be carrying out our third year of data collection with our pupil cohort, who have reached the age of 10 to 11.
We’ll also be running a survey next summer for upper primary-aged children and their teachers. Please sign up for our Teacher Research Network newsletter to be the first to hear about taking part in this survey.
As part of our TICE project we support teachers to conduct their own action research projects. This is a collaborative project, involving academics across the UK who volunteer to support teachers. The goal is to enable teachers to take a deep dive into a curriculum topic, a pedagogical approach, or a new resource, or to address a wider issue such as gender diversity or accessibility, to inform a change in their practice.
This year 16 teachers published their reports in our Teacher Research Booklet, and many also presented their findings online at CAS events or at the KCL-CAS London conference and the CAS National Conference. We’re very proud of them!
Two of our TICE teachers will be also presenting their research at an academic conference to be held in January. Congratulations to Will Grey and Joanne Hodge!
There are many other projects you can find out about on our website and in our annual report, so I hope that you will keep reading. It goes without saying that I’m incredibly proud of the team who’ve worked on all of these projects!
To summarise, here’s how you can stay up to date with our work and maybe even get involved in studies:
Finally, I am pleased to announce that we will be hosting the UKICER 2026 conference for researchers and teachers in Cambridge on 3 and 4 2026 September. More details will follow on the UKICER website and on the Research Centre website in due course.
The post 2025 highlights from the Raspberry Pi Computing Education Research Centre appeared first on Raspberry Pi Foundation.
Take a minute to think about the technology you use every day. How many programming hours went into the way you are reading this blog post? What discussions and solutions built the browser you’re using? We take for granted all the clever, creative programming that goes into the technology we use in our daily lives. But how do we best teach programming to support the next generation of innovators?
The brand-new issue of Hello World — and our new podcast mini series — aims to answer that question. This issue is packed with insightful research, practical advice, and thoughtful ways to best teach programming in your classroom.
In their articles for issue 28, educators explore a range of topics related to teaching programming, such as:
Our feature articles also include:
Simon Peyton Jones, British computer scientist and Member of the Raspberry Pi Foundation, says in his article ‘Programming the Future’:
“Designing and writing software is one of the most demanding, intellectually stretching tasks that humans undertake. If we build a building, we are limited by the strength of steel — we can only make the tower so high before it will fall under its own weight. But software knows no such limits. The only limit is our own ability (or inability) to manage the complexity of the systems we build. That is humbling — but also exciting.”
Programming is exciting, and we hope Hello World issue 28 inspires you to continue doing the important work of educating the next generation of programmers and innovators. This issue will provide you with plenty of ideas to take away and build upon.
Also in issue 28:
And much, much more.
Let us know which articles you found most thought-provoking, and which will be most helpful for your teaching, by sending us a message or tagging us on social media.
Thank you to Oracle for sponsoring this issue of Hello World.
The post Hello World #28 out now: Teaching programming appeared first on Raspberry Pi Foundation.
Today we are starting a campaign to support every school and library in the UK to set up a free Code Club to make sure that all young people can develop the skills and knowledge they need to thrive in the age of AI.
Over the past decade, Code Club has provided more than 2 million young people with the opportunity to learn how to build their own apps, games, animations, websites, robots, and so much more.
We know that getting hands-on, practical experience of building real projects with technology works. Independent evaluations have shown that attending a Code Club not only helps young people develop their programming skills, but also builds wider life skills such as confidence, resilience, problem-solving, and communication. All of which we know are essential if they are going to thrive in a world where AI is ubiquitous.
Right now, there are over 2,000 Code Clubs meeting in schools and libraries all over the UK, organised by an amazing community of teachers, educators, and volunteers from all walks of life. We want to see that number grow.
You don’t need technical skills to mentor at a Code Club. The Raspberry Pi Foundation provides free, self-guided projects that help young people learn how to create with different technologies. We have over 200 Code Club Projects on our website, all of which are developed by expert educators, based on evidence of how young people learn, and rigorously tested; so we know that they are effective.
That includes a set of projects that support the safe exploration of AI technologies, helping young people understand how AI works, its possibilities and limitations.
We also provide training and support to help you set up and run your Code Club, all of which is available at no charge.
I can promise you that the hour you spend in a Code Club will be the highlight of your week. I always come away from Code Club inspired and optimistic about what young people can achieve if we give them a sense of agency over technology.
If you have been inspired to set up your own Code Club, you can find all the information you need to run your own club here.
You don’t have to take my word for it: here’s Janine, a Computer Science teacher and long-time Code Club mentor from Stoke-on-Trent sharing her experience.
Janine Kirk is a Computer Science Teacher at The King’s Church of England Academy in Stoke-on-Trent, UK, who has been running a Code Club for over ten years. She has been inspired by the campaign for a Code Club in every school and library in the UK, to set up clubs in six other schools in her multi-academy trust.
Setting up a Code Club is really easy as a teacher, as you can just tag it onto the end of your school day, or during lunch. The website is clear and easy to use — and once you have signed up, you have access to additional resources to promote your club. Code Club gives time and space to explore coding in a completely different way than in a classroom. For me, it’s about seeing what programs really inspire students: it gives an insight into how students like to code, ideas of preferred coding language, and tasks they keep coming back to. Running a Code Club has also allowed me to build relationships with students outside of the classroom environment, and all of this spills into my lessons and improves my teaching practice.
For students, Code Club is a great space where they can collaborate and work on their chosen tasks. Students often comment on how they look forward to Code Club and how they have continued their projects at home. It also allows students much more variety in enrichment activity, as Code Club is often popular with students who are neurodivergent. It’s amazing to see the children grow in confidence and friendship as they find likeminded students to support each other.
My students really love the certificates they can earn. We have been inspired by the excellent activities that revamp the old ways of teaching programming and give them a really nice spin. In fact, I have used the resources in computer science lessons too, as they are often much more visual and fun for the students to create.
Since joining Code Club I have felt part of a community. I receive regular updates, and attending events such as the Clubs Conference really helps inspire creative ways to teach coding. As a computing teacher in a secondary school, you are often part of a very small team — but Code Club has allowed me to feel part of something bigger, and I know that should I need support, they are always there with friendly advice. It really is the best thing that I have done in my career.
Are you inspired to set up your own Code Club? Then find more information on how to get started running a club today.
The post A Code Club in every school and library appeared first on Raspberry Pi Foundation.
Creating a computer program involves many different skills — knowing how to code is just one part. When we teach programming to young people, we want to guide them to learn these skills in a structured way. The ‘levels of abstraction’ framework is a great tool for doing that. This blog describes how using the framework will benefit you and your learners in the computing classroom.
We’re also excited to share our new Pedagogy Quick Read, which you can download for free to:
Creating a program from the ground up can be daunting, especially for new learners. Without support, they’ll likely get stuck sooner or later; programs rarely work the first time round. And the more complex the problem that a program is addressing, the more likely it is that the first version of the program won’t work.
One reason that learning to program can be challenging is that it involves understanding a lot of specific concepts and applying many varied skills. From early on in their learning journey, young people need to have a firm grasp of concepts such as repetition, selection, variables, and functions. Also fundamental to learning to program well is the skill of abstraction: understanding a task and identifying which details are relevant and which can be ignored.
To get to grips with all these different concepts and skills, young people need structure — otherwise they’ll try to hold everything in their head at once, and likely feel overwhelmed by the cognitive load. This sort of experience may cause them to disengage instead of persisting. They may even decide that programming is not for them.
In light of these challenges, the ‘levels of abstraction’ framework is a great tool for teaching.
The framework breaks programming down into four levels, each focusing on a different aspect of creating a program:
Throughout the processes of developing a program, learners (and professional programmers) move between these levels as they implement their designs and debug them, sometimes even returning to the problem level if more analysis or clarification is needed.
Potential benefits of the ‘levels of abstraction’ framework for teachers:
Potential benefits for learners:
Our new Quick Read shares tips on how to best use the framework in your teaching.
Things to aim for when using the framework with your learners:
We hope you find the framework useful. If you have ideas for how to use it in your teaching, why not share them in the comments?
When following the ‘levels of abstraction’ approach, learners need to explain how programs work and debug them. That means program comprehension is a key skill here. You may have already helped your learners to develop and practise this skill, for example with the PRIMM approach. The Block Model is another useful tool for helping your learners talk about various aspects of a program. And if you use the pair programming approach in programming activities, your learners can improve their program comprehension by talking about their code with each other. On our website, you’ll find more guidance on the best ways to teach programming and computing.
And what about generative artificial intelligence (AI) tools for programmers? In the age of AI, we think young people still need to learn to code because it empowers them to navigate and think critically about all digital technologies, including AI. And while generative AI tools can help a skilled programmer create quality code more quickly, more research is needed to show whether such tools help school-age young people build their understanding as they learn to code. You can see some of the great work being done in this area if you catch up with our 2024 research seminar series.
The ‘levels of abstraction’ framework is useful in your teaching no matter what tools young people use to create programs. Even with an AI tool, they will still need to work at all four levels of abstraction to program effectively.
The post How to give your students structure as they learn programming skills appeared first on Raspberry Pi Foundation.
Today we’re publishing a position paper setting out five arguments for why we think that kids still need to learn to code in the age of artificial intelligence.
Just like every wave of technological innovation that has come before, the advances in artificial intelligence (AI) are raising profound questions about the future of human work. History teaches us that technology has the potential to both automate and augment human effort, destroying some jobs and creating new ones. The only thing we know for sure is that it is impossible to predict the precise nature and pace of the changes that are coming.
One of the fastest-moving applications of generative AI technologies are the systems that can generate code. What started as the coding equivalent of autocomplete has quickly progressed to tools that can generate increasingly complex code from natural language prompts.
This has given birth to the notion of “vibe-coding” and led some commentators to predict the end of the software development industry as we know it. It shouldn’t be a surprise then that there is a vigorous debate about whether kids still need to learn to code.
In the position paper we put forward five arguments for why we think the answer is an unequivocal yes.
First, we argue that even in a world where AI can generate code, we need skilled human programmers who can think critically, solve problems, and make ethical decisions. The large language models that underpin these tools are probabilistic systems designed to provide statistically acceptable outputs and, as any skilled software engineer will tell you, simply writing more code faster isn’t necessarily a good thing.
Learning to code is the most effective way we know for a young person to develop the mental models and fluency to become a skilled human programmer. The hard cognitive work of reading, modifying, writing, explaining, and testing code is precisely how young people develop a deep understanding of programming and computational thinking.
While there’s no doubt that AI is going to reshape the labour market, the evidence from history suggests that it will increase the reach of programming and computational approaches across the economy and into new domains, creating demand for humans who are skilled programmers. We also argue that coding is no longer just for software engineers, it’s becoming a core skill that enables people to work effectively and think critically in a world shaped by intelligent machines. From healthcare to agriculture, we are already seeing demand for people who can combine programming with domain-specific skills and craft knowledge.
Alongside the arguments for coding as a route to opening up economic opportunities, we argue that coding and programming gives young people a way to express themselves, to learn, and to make sense of the world.
And perhaps most importantly, that learning to code is about power. Providing young people with a solid grounding in computational literacy, developed through coding, helps ensure that they have agency. Without it, they risk being manipulated by systems they don’t understand. As Rushkoff said: “Program, or be programmed”.
Finally, we argue that the power to create with technology is already concentrated in too small and homogenous a group of people. We need to open up the opportunity to learn to code to all young people because it will help us mobilise the full potential of human talent, will lead to more inclusive and effective digital solutions to the big global challenges we face, and will help ensure that everyone can share in the societal and economic benefits of technological progress.
We end the paper with a call to action for all of us working in education. We need to challenge the false narrative that AI is removing the need for kids to learn to code, and redouble our efforts to ensure that all young people are equipped to take advantage of the opportunities in a world where AI is ubiquitous.
You can read the full paper here:
The cartoon image for this blog was created using ChatGPT-4o, which was prompted to produce a “whimsical cartoon that expresses some of the key ideas in the position paper”. It took several iterations.
The post Why kids still need to learn to code in the age of AI appeared first on Raspberry Pi Foundation.
Generative AI (GenAI) tools like GitHub Copilot and ChatGPT are rapidly changing how programming is taught and learnt. These tools can solve assignments with remarkable accuracy. GPT-4, for example, scored an impressive 99.5% on an undergraduate computer science exam, compared to Codex’s 78% just two years earlier. With such capabilities, researchers are shifting from asking, “Should we teach with AI?” to “How do we teach with AI?”
Leo Porter and Daniel Zingaro have spearheaded this transformation through their groundbreaking undergraduate programming course. Their innovative curriculum integrates GenAI tools to help students tackle complex programming tasks while developing critical thinking and problem-solving skills.
Leo and Daniel presented their work at the Raspberry Pi Foundation research seminar in December 2024. During the seminar, it became clear that much could be learnt from their work, with their insights having particular relevance for teachers in secondary education thinking about using GenAI in their programming classes
In 2023, Leo and Daniel introduced GitHub Copilot in their introductory programming CS1-LLM course at UC San Diego with 550 students. The course included creative, open-ended projects that allowed students to explore their interests while applying the skills they’d learnt. The projects covered the following areas:
Students consistently reported that these projects were not only enjoyable but also responsible for deepening their understanding of programming concepts. A majority (74%) found the projects helpful or extremely helpful for their learning. One student noted that.
“Programming projects were fun and the amount of freedom that was given added to that. The projects also helped me understand how to put everything that we have learned so far into a project that I could be proud of.“
Leo and Daniel emphasised that teaching programming with GenAI involves fostering a mix of traditional and AI-specific skills.
Their approach centres on six core competencies:
Ethical and metacognitive skills: Students engage in discussions about responsible AI use and reflect on the decisions they make when collaborating with AI tools.
The rise of GenAI has prompted educators to rethink how they assess programming skills. In the CS1-LLM course, traditional take-home assignments were de-emphasised in favour of assessments that focused on process and understanding.
While Leo and Daniel reported that the integration of AI tools into their course has been largely successful, it has also introduced challenges. Surveys revealed that some students felt overly dependent on AI tools, expressing concerns about their ability to code independently. Addressing this will require striking a balance between leveraging AI tools and reinforcing foundational skills.
Additionally, ethical concerns around AI use, such as plagiarism and intellectual property, must be addressed. Leo and Daniel incorporated discussions about these issues into their curriculum to ensure students understand the broader implications of working with AI technologies.
Leo and Daniel’s work demonstrates that GenAI can transform programming education, making it more inclusive, engaging, and relevant. Their course attracted a diverse cohort of students, as well as students traditionally underrepresented in computer science — 52% of the students were female and 66% were not majoring in computer science — highlighting the potential of AI-powered learning to broaden participation in computer science.
By embracing this shift, educators can prepare students not just to write code but to also think critically, solve real-world problems, and effectively harness the AI innovations shaping the future of technology.
If you’re an educator interested in using GenAI in your teaching, we recommend checking out Leo and Daniel’s book, Learn AI-Assisted Python Programming, as well as their course resources on GitHub. You may also be interested in our own Experience AI resources, which are designed to help educators navigate the fast-moving world of AI and machine learning technologies.
Our 2025 seminar series is exploring how we can teach young people about AI technologies and data science. At our next seminar on Tuesday, 11 March at 17:00–18:00 GMT, we’ll hear from Lukas Höper and Carsten Schulte from Paderborn University. They’ll be discussing how to teach school students about data-driven technologies and how to increase students’ awareness of how data is used in their daily lives.
To sign up and take part in the seminar, click the button below — we’ll then send you information about joining. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars and recordings page.
The post Integrating generative AI into introductory programming classes appeared first on Raspberry Pi Foundation.
Artificial intelligence (AI) continues to change many areas of our lives, with new AI technologies and software having the potential to significantly impact the way programming is taught at schools. In our seminar series this year, we’ve already heard about new AI code generators that can support and motivate young people when learning to code, AI tools that can create personalised Parson’s Problems, and research into how generative AI could improve young people’s understanding of program error messages.
At times, it can seem like everything is being automated with AI. However, there are some parts of learning to program that cannot (and probably should not) be automated, such as understanding errors in code and how to fix them. Manually typing code might not be necessary in the future, but it will still be crucial to understand the code that is being generated and how to improve and develop it.
As important as debugging might be for the future of programming, it’s still often the task most disliked by novice programmers. Even if program error messages can be explained in the future or tools like LitterBox can flag bugs in an engaging way, actually fixing the issues involves time, effort, and resilience — which can be hard to come by at the end of a computing lesson in the late afternoon with 30 students crammed into an IT room.
But what is it about debugging that young people find so hard, even when they’re given enough time to do it? And how can we make debugging a more motivating experience for young people? These are two of the questions that Laurie Gale, a PhD student at the Raspberry Pi Computing Education Research Centre, focused on in our July seminar.
Laurie has spent the past two years talking to teachers and students and developing tools (a visualiser of students’ programming behaviour and PRIMMDebug, a teaching process and tool for debugging) to understand why many secondary school students struggle with debugging. It has quickly become clear through his research that most issues are due to problematic debugging strategies and students’ negative experiences and attitudes.
When students first start learning how to program, they have to remember a vast amount of new information, such as different variables, concepts, and program designs. Utilising this knowledge is often challenging because they’re already busy juggling all the content they’ve previously learnt and the challenges of the programming task at hand. When error messages inevitably appear that are confusing or misunderstood, it can become extremely difficult to debug effectively.
Given this information overload, students often don’t develop efficient strategies for debugging. When Laurie analysed the debugging efforts of 12- to 14-year-old secondary school students, he noticed some interesting differences between students who were more and less successful at debugging. While successful students generally seemed to make less frequent and more intentional changes, less successful students tinkered frequently with their broken programs, making one- or two-character edits before running the program again. In addition, the less successful students often ran the program soon after beginning the debugging exercise without allowing enough time to actually read the code and understand what it was meant to do.
The issue with these behaviours was that they often resulted in students adding errors when changing the program, which then compounded and made debugging increasingly difficult with each run. 74% of students also resorted to spamming, pressing ‘run’ again and again without changing anything. This strategy resonated with many of our seminar attendees, who reported doing the same thing after becoming frustrated.
Educators need to be aware of the negative consequences of students’ exasperating and often overwhelming experiences with debugging, especially if students are less confident in their programming skills to begin with. Even though spending 15 minutes on an exercise shows a remarkable level of tenaciousness and resilience, students’ attitudes to programming — and computing as a whole — can quickly go downhill if their strategies for identifying errors prove ineffective. Debugging becomes a vicious circle: if a student has negative experiences, they are less confident when having to bug-fix again in the future, which can lead to another set of unsuccessful attempts, which can further damage their confidence, and so on. Avoiding this downward spiral is essential.
Laurie stresses the importance of understanding the cognitive challenges of debugging and using the right tools and techniques to empower students and support them in developing effective strategies.
Some ideas of how to improve debugging skills that were mentioned by Laurie and our attendees included:
Most importantly, debugging should not be a daunting or stressful experience. Everyone in the seminar agreed that creating a positive error culture is essential.
Some ideas you could explore in your classroom include:
In a welcoming classroom where students are given support and encouragement, debugging can be a rewarding experience. What may at first appear to be a failure — even a spectacular one — can be embraced as a valuable opportunity for learning. As a teacher in Laurie’s study said, “If something should have gone right and went badly wrong but somebody found something interesting on the way… you celebrate it. Take the fear out of it.”
Watch the recording of Laurie’s presentation:
In our current seminar series, we are exploring how to teach programming with and without AI.
Join us at our next seminar on Tuesday, 12 November at 17:00–18:30 GMT to hear Nicholas Gardella (University of Virginia) discuss the effects of using tools like GitHub Copilot on the motivation, workload, emotion, and self-efficacy of novice programmers. To sign up and take part in the seminar, click the button below — we’ll then send you information about joining. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars and recordings page.
The post How to make debugging a positive experience for secondary school students appeared first on Raspberry Pi Foundation.
To empower every educator to confidently bring AI into their classroom, we’ve created a new online training course called ‘Understanding AI for educators’ in collaboration with Google DeepMind. By taking this course, you will gain a practical understanding of the crossover between AI tools and education. The course includes a conceptual look at what AI is, how AI systems are built, different approaches to problem-solving with AI, and how to use current AI tools effectively and ethically.
In this post, I will share our approach to designing the course and some of the key considerations behind it — all of which you can apply today to teach your learners about AI systems.
We know educators have different levels of confidence with AI tools — we designed this course to help create a level playing field. Our goal is to uplift every educator, regardless of their prior experience, to a point where they feel comfortable discussing AI in the classroom.
AI literacy is key to understanding the implications and opportunities of AI in education. The course provides educators with a solid conceptual foundation, enabling them to ask the right questions and form their own perspectives.
As with all our AI learning materials that are part of Experience AI, we’ve used specific design principles for the course:
The course offers three main takeaways any educator can apply to their teaching about AI systems.
Deciding the level of detail to use when talking about AI systems can be difficult — especially if you’re not very confident about the topic. The SEAME framework offers a solution by breaking down AI into 4 levels: social and ethical, application, model, and engine. Educators can focus on the level most relevant to their lessons and also use the framework as a useful structure for classroom discussions.
You might discuss the impact a particular AI system is having on society, without the need to explain to your learners how the model itself has been trained or tested. Equally, you might focus on a specific machine learning model to look at where the data used to create it came from and consider the effect the data source has on the output.
AI applications can be broadly separated into two categories: predictive and generative. These two types of AI model represent two vastly different approaches to problem-solving.
People create predictive AI models to make predictions about the future. For example, you might create a model to make weather forecasts based on previously recorded weather data, or to recommend new movies to you based on your previous viewing history. In developing predictive AI models, the problem is defined first — then a specific dataset is assembled to help solve it. Therefore, each predictive AI model usually is only useful for a small number of applications.
Generative AI models are used to generate media (such as text, code, images, or audio). The possible applications of these models are much more varied because people can use media in many different kinds of ways. You might say that the outputs of generative AI models could be used to solve — or at least to partially solve — any number of problems, without these problems needing to be defined before the model is created.
Generative AI systems rely on user prompts to generate outputs. The OCEAN process, outlined in the course, offers a simple yet powerful framework for prompting AI tools like Gemini, Stable Diffusion or ChatGPT.
The first three steps of the process help you write better prompts that will result in an output that is as close as possible to what you are looking for, while the last two steps outline how to improve the output:
The final step in using any generative AI tool should be to closely review or edit the output yourself. These tools will very quickly get you started but you’ll always have to rely on your own human effort to ensure the quality of your work.
We believe the knowledge and skills our ‘Understanding AI for educators’ course teaches will help any educator determine the right AI tools and concepts to bring into their classroom, regardless of their specialisation. Here’s what one course participant had to say:
“From my inexperienced viewpoint, I kind of viewed AI as a cheat code. I believed that AI in the classroom could possibly be a real detriment to students and eliminate critical thinking skills.
After learning more about AI [on the course] and getting some hands-on experience with it, my viewpoint has certainly taken a 180-degree turn. AI definitely belongs in schools and in the workplace. It will take time to properly integrate it and know how to ethically use it. Our role as educators is to stay ahead of this trend as opposed to denying AI’s benefits and falling behind.” – ‘Understanding AI for educators’ course participant
All our Experience AI resources — including this online course and the teaching materials — are designed to foster a generation of AI-literate educators who can confidently and ethically guide their students in navigating the world of AI.
You can sign up to the course for free here:
A version of this article also appears in Hello World issue 25, which will be published on Monday 23 September and will focus on all things generative AI and education.
The post Free online course on understanding AI for educators appeared first on Raspberry Pi Foundation.
As discussions of how artificial intelligence (AI) will impact teaching, learning, and assessment proliferate, I was thrilled to be able to add one of my own research projects to the mix. As a research scientist at the Raspberry Pi Foundation, I’ve been working on a pilot research study in collaboration with Jane Waite to explore the topic of program error messages (PEMs).
PEMs can be a significant barrier to learning for novice coders, as they are often confusing and difficult to understand. This can hinder troubleshooting and progress in coding, and lead to frustration.
Recently, various teams have been exploring how generative AI, specifically large language models (LLMs), can be used to help learners understand PEMs. My research in this area specifically explores secondary teachers’ views of the explanations of PEMs generated by a LLM, as an aid for learning and teaching programming, and I presented some of my results in our ongoing seminar series.
I started the seminar by setting the scene and describing the current background of research on novices’ difficulty in using PEMs to fix their code, and the efforts made to date to improve these. The three main points I made were that:
My pilot study aims to fill this gap directly, by reporting K–12 teachers’ views of the potential use of LLM-generated explanations of PEMs in the classroom, and how their views fit into the wider theoretical paradigm of feedback literacy.
To conduct the study, I interviewed eight expert secondary computing educators. The interviews were semi-structured activity-based interviews, where the educators got to experiment with a prototype version of the Foundation’s publicly available Code Editor. This version of the Code Editor was adapted to generate LLM explanations when the question mark next to the standard error message is clicked (see Figure 1 for an example of a LLM-generated explanation). The Code Editor version called the OpenAI GPT-3.5 interface to generate explanations based on the following prompt: “You are a teacher talking to a 12-year-old child. Explain the error {error} in the following Python code: {code}”.
Fifteen themes were derived from the educators’ responses and these were split into five groups (Figure 2). Overall, the educators’ views of the LLM feedback were that, for the most part, a sensible explanation of the error messages was produced. However, all educators experienced at least one example of invalid content (LLM “hallucination”). Also, despite not being explicitly requested in the LLM prompt, a possible code solution was always included in the explanation.
Next, I investigated how the teachers’ views correlated to the research conducted to date on enhanced PEMs. I used the guidelines proposed by Brett Becker and colleagues, which consolidate a lot of the research done in this area into ten design guidelines. The guidelines offer best practices on how to enhance PEMs based on cognitive science and educational theory empirical research. For example, they outline that enhanced PEMs should provide scaffolding for the user, increase readability, reduce cognitive load, use a positive tone, and provide context to the error.
Out of the 15 themes identified in my study, 10 of these correlated closely to the guidelines. However, the 10 themes that correlated well were, for the most part, the themes related to the content of the explanations, presentation, and validity (Figure 3). On the other hand, the themes concerning the teaching and learning process did not fit as well to the guidelines.
However, when I looked at feedback literacy theory, I was able to correlate all fifteen themes — the theory fits.
Feedback literacy theory positions the feedback process (which includes explanations) as a social interaction, and accounts for the actors involved in the interaction — the student and the teacher — as well as the relationships between the student, the teacher, and the feedback. We can explain feedback literacy theory using three constructs: feedback types, student feedback literacy, and teacher feedback literacy (Figure 4).
From the feedback literacy perspective, feedback can be grouped into four types: telling, guiding, developing understanding, and opening up new perspectives. The feedback type depends on the role of the student and teacher when engaging with the feedback (Figure 5).
From the student perspective, the competencies and dispositions students need in order to use feedback effectively can be stated as: appreciating the feedback processes, making judgements, taking action, and managing affect. Finally, from a teacher perspective, teachers apply their feedback literacy skills across three dimensions: design, relational, and pragmatic.
In short, according to feedback literacy theory, effective feedback processes entail well-designed feedback with a clear pedagogical purpose, as well as the competencies students and teachers need in order to make sense of the feedback and use it effectively.
This theory therefore provided a promising lens for analysing the educators’ perspectives in my study. When the educators’ views were correlated to feedback literacy theory, I found that:
By correlating educators’ views to feedback literacy theory as well as enhanced PEM guidelines, we can take a broader perspective on how LLMs might not only shape the content of the explanations, but the whole social interaction around giving and receiving feedback. Investigating ways of supporting students and teachers to practise their feedback literacy skills matters just as much, if not more, than focusing on the content of PEM explanations.
This study was a first-step exploration of eight educators’ views on the potential impact of using LLM explanations of PEMs in the classroom. Exactly what the findings of this study mean for classroom practice remains to be investigated, and we also need to examine students’ views on the feedback and its impact on their journey of learning to program.
If you want to hear more, you can watch my seminar:
You can also read the associated paper, or find out more about the research instruments on this project website.
If any of these ideas resonated with you as an educator, student, or researcher, do reach out — we’d love to hear from you. You can contact me directly at veronica.cucuiat@raspberrypi.org or drop us a line in the comments below.
The focus of our ongoing seminar series is on teaching programming with or without AI. Check out the schedule of our upcoming seminars.
To take part in the next seminar, click the button below to sign up, and we will send you information about how to join. We hope to see you there.
You can also catch up on past seminars on our blog and on the previous seminars and recordings page.
The post How useful do teachers find error message explanations generated by AI? Pilot research results appeared first on Raspberry Pi Foundation.
Registration is now open for the European Astro Pi Challenge 2024/25! The Astro Pi Challenge, an ESA Education project run in collaboration with us here at the Raspberry Pi Foundation, offers young people the incredible opportunity to write computer programs that will run in space.
Young people can take part in two exciting missions for beginners and more experienced coders, and send their code to run on special Raspberry Pi computers, called Astro Pis, on board the International Space Station (ISS).
We are delighted that new ESA project astronaut Sławosz Uznański will be the ambassador for this year’s Astro Pi Challenge. Sławosz, born in Poland in 1984, has a background in space systems engineering and has conducted research in radiation effects. He recently served as the Engineer in Charge of CERN’s largest accelerator, the Large Hadron Collider.
In Mission Zero, young people create beautiful pixel art to display on the Astro Pis’ LED screens. This mission requires no prior experience of Python coding, and it can be completed in around an hour.
To take part, young people design and code pixel art inspired by nature on Earth and beyond, to display on the Astro Pi computers for the astronauts on the ISS to see as they go about their daily tasks.
Using our step-by-step Mission Zero project guide, young people will learn to create simple Python programs in which they will code with variables and use the colour sensors on the Astro Pis to change the background colour in their images. To help your teams create their designs, check out the examples from teams that took part in Mission Zero in 2023/24 in the project guide.
Young people can create their Mission Zero programs individually or in teams of up to 4 people, and this year, we have added a save function for young people as they code. This will make it easier for mentors to run Mission Zero over more than one session, and also means that young people can finish their projects at home. They will need to use your classroom code and their team name to load their saved projects.
Mission Space Lab asks teams to solve a real-world scientific task in space. It is ideally suited to young people who would like to learn more about space science and stretch their programming skills.
In Mission Space Lab this year, the task for teams of 2 to 6 young people is to calculate the speed at which the International Space Station is travelling — as accurately as possible. Teams need to write a Python program that:
This year we have created a new way for teams to test their programs, with an online version of the Astro Pi Replay tool. All teams need to do is select their program and run it in Astro Pi Replay, which will create a real-time simulation of the program running on the ISS, using historical data and images. Astro Pi Replay will also show program outputs and report errors. This means teams can code their program in their preferred code editor, then test with an internet browser. However, if they wish, teams can still run the Astro Pi Replay tool offline with Thonny.
Both missions are open to young people up to age 19 from eligible countries — all ESA Member States and beyond. To find out more and register, visit astro-pi.org.
Look out for updates and resources being shared on the Astro Pi website, including a Mission Zero video codealong and Mission Space Lab live streams. You can also keep up-to-date with all the Astro Pi news on the Astro Pi X account, our Facebook, LinkedIn, and Instagram, or by signing up to the newsletter at astro-pi.org.
We can’t wait to see your programs!
The post The European Astro Pi Challenge 2024/25 launches today appeared first on Raspberry Pi Foundation.
We have developed an innovative activity to support young people as they transition from visual programming languages like Scratch to text-based programming languages like Python.
This activity introduces a unique interface that empowers learners to easily interact with Python while they create a customised painting app.
“The kids liked the self-paced learning, it allowed them to work at their own rate. They liked using RGB tables to find their specific colours.” – Code Club mentor
We’ve long been championing Python as an ideal tool for young people who want to start text-based programming. Python has simple syntax and needs very few lines of code to get started, and there is a vibrant community of supportive programmers surrounding it.
However, we know that starting with Python can be challenging for young people who have never done any text-based coding. They can face obstacles such as software installation issues, getting used to a new syntax, and the need for appropriate typing skills.
‘Paint with Python’ is an online educational activity that addresses many of these challenges and helps young people learn to code Python for the first time. It’s entirely web-based, requiring no software installation beyond a web browser. Instructions are displayed in a side panel, allowing learners to read and code without needing to switch tabs.
To help young people with creating their painting app, much of the initial code is pre-written behind the scenes, which enables learners to focus on experimenting with Python and observing the outcomes. They engage with the code by clicking on suggested options or, in some cases, by typing small snippets of Python. For example, they can select colours from a range of options or, as they grow more confident, type RGB values to create custom colours.
The activity is fully responsive for mobile and tablet devices and provides a final view of the full program on the last page, together with suggested routes to continue learning text-based programming.
We believe this activity offers an accessible way for young learners to begin their journey with text-based programming and learning to code Python. The code they write is straightforward and the activity is designed to minimise errors. When mistakes do occur, the interface provides clear, constructive feedback, guiding learners to make corrections.
Try out ‘Paint with Python’ at rpf.io/paint-with-python. We’d love to hear your feedback! Please send any thoughts you have to uxresearch@raspberrypi.org.
This activity was developed with support from the Cisco Foundation. Through our funding partnership with them, we’ve been able to provide thousands of young people with the inspiration and opportunity to progress their coding skills anywhere, and on any device.
The post Bridging the gap from Scratch to Python: Introducing ‘Paint with Python’ appeared first on Raspberry Pi Foundation.
Generative artificial intelligence (AI) tools are becoming more easily accessible to learners and educators, and increasingly better at generating code solutions to programming tasks, code explanations, computing lesson plans, and other learning resources. This raises many questions for educators in terms of what and how we teach students about computing and AI, and AI’s impact on assessment, plagiarism, and learning objectives.
We were honoured to have Professor Brett Becker (University College Dublin) join us as part of our ‘Teaching programming (with or without AI)’ seminar series. He is uniquely placed to comment on teaching computing using AI tools, having been involved in many initiatives relevant to computing education at different levels, in Ireland and beyond.
Brett’s talk focused on what educators and education systems need to do to prepare all students — not just those studying Computing — so that they are equipped with sufficient knowledge about AI to make their way from primary school to secondary and beyond, whether it be university, technical qualifications, or work.
Brett began his talk by illustrating the increase in performance of large language models (LLMs) in solving first-year undergraduate programming exercises: he compared the findings from two recent studies he was involved in as part of an ITiCSE Working Group. In the first study — from 2021 — the results generated by GPT-3 were similar to those of students in the top quartile. By the second study in 2023, GPT-4’s performance matched that of a top student (Figure 1).
Figure 1: Student scores on Exam 1 and Exam 2, represented by circles. GPT-3’s 2021 score is represented by the blue ‘x’, and GPT-4’s 2023 score on the same questions is represented by the red ‘x’.
Brett also explained that the study found some models were capable of solving current undergraduate programming assessments almost error-free, and could solve the Irish Leaving Certificate and UK A level Computer Science exams.
This level of performance raises many questions for computing educators about what is taught and how to assess students’ learning. To address this, Brett referred to his 2023 paper, which included findings from a literature review and a survey on students’ and instructors’ attitudes towards using LLMs in computing education. This analysis has helped him identify several opportunities as well as the ethical challenges education systems face regarding generative AI.
The opportunities include:
Some of the challenges include:
Next, Brett talked about concrete actions that he thinks we need to take in response to these opportunities and challenges.
He emphasised our responsibility to keep students safe. One way to do this is to empower all students with a baseline level of knowledge about AI, at an age-appropriate level, to enable them to keep themselves safe.
He also discussed the increased relevance of programming to all subjects, not only Computing, in a similar way to how reading and mathematics transcend the boundaries of their subjects, and the need he sees to adapt subjects and curricula to that effect.
As an example of how rapidly curricula may need to change with increasing AI use by students, Brett looked at the Irish Computer science specification for “senior cycle” (final two years of second-level, ages 16–18). This curriculum was developed in 2018 and remains a strong computing curriculum in Brett’s opinion. However, he pointed out that it only contains a single learning outcome on AI.
To help educators bridge this gap, in the book Brett wrote alongside Keith Quille to accompany the curriculum, they included two chapters dedicated to AI, machine learning, and ethics and computing. Brett believes these types of additional resources may be instrumental for teaching and learning about AI as resources are more adaptable and easier to update than curricula.
Taking the opportunity to use generative AI to reimagine new types of programming problems, Brett and colleagues have developed Promptly, a tool that allows students to practise prompting AI code generators. This tool provides a combined approach to learning about generative AI while learning programming with an AI tool.
Promptly is intended to help students learn how to write effective prompts. It encourages students to specify and decompose the programming problem they want to solve, read the code generated, compare it with test cases to discern why it is failing (if it is), and then update their prompt accordingly (Figure 2).
Figure 2: Example of a student’s use of Promptly.
Early undergraduate student feedback points to Promptly being a useful way to teach programming concepts and encourage metacognitive programming skills. The tool is further described in a paper, and whilst the initial evaluation was aimed at undergraduate students, Brett positioned it as a secondary school–level tool as well.
Brett hopes that by using generative AI tools like this, it will be possible to better equip a larger and more diverse pool of students to engage with computing.
Brett concluded his seminar by broadening the relevance of programming to all learners, while challenging us to expand our perspectives of what programming is. If we define programming as a way of prompting a machine to get an output, LLMs allow all of us to do so without the need for learning the syntax of traditional programming languages. Taking that view, Brett left us with a question to consider: “How do we prepare for this from an educational perspective?”
You can watch Brett’s presentation here:
The focus of our ongoing seminar series is on teaching programming with or without AI.
For our next seminar on Tuesday 11 June at 17:00 to 18:30 GMT, we’re joined by Veronica Cucuiat (Raspberry Pi Foundation), who will talk about whether LLMs could be employed to help understand programming error messages, which can present a significant obstacle to anyone new to coding, especially young people.
To take part in the seminar, click the button below to sign up, and we will send you information about how to join. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our blog and on the previous seminars and recordings page.
The post Imagining students’ progression in the era of generative AI appeared first on Raspberry Pi Foundation.
I’m excited to announce that we’re developing a new set of Code Editor features to help school teachers run text-based coding lessons with their students.
Last year we released our free Code Editor and made it available as an open source project. Right now we’re developing a new set of features to help schools use the Editor to run text-based coding lessons online and in-person.
The new features will enable educators to create coding activities in the Code Editor, share them with their students, and leave feedback directly on each student’s work. In a simple and easy-to-use interface, educators will be able to give students access, group them into classes within a school account, and quickly help with resetting forgotten passwords.
We’re adding these teaching features to the Code Editor because one of the key problems we’ve seen educators face over the last few months has been the lack of an ideal tool to teach text-based coding in the classroom. There are some options available, but they can be cost-prohibitive for schools and educators. Our mission is to support young people to realise their full potential through the power of computing, and we believe that to tackle educational disadvantage, we need to offer high-quality tools and make them as accessible as possible. This is why we’ll offer the Code Editor and all its features to educators and students for free, forever.
Alongside the new classroom management features, we’re also working on improved Python library support for the Code Editor, so that you and your students can get more creative and use the Editor for more advanced topics. We continue to support HTML, CSS, and JavaScript in the Editor too, so you can set website development tasks in the classroom.
Educators have already been incredibly generous in their time and feedback to help us design these new Code Editor features, and they’ve told us they’re excited to see the upcoming developments. Pete Dring, Head of Computing at Fulford School, participated in our user research and said on LinkedIn: “The class management and feedback features they’re working on at the moment look really promising.” Lee Willis, Head of ICT and Computing at Newcastle High School for Girls, also commented on the Code Editor: “We have used it and love it, the fact that it is both for HTML/CSS and then Python is great as the students have a one-stop shop for IDEs.”
We’re working to have the Code Editor’s new teaching features ready later this year. We’ll launch the setup journey sooner, so that you can pre-register for your school account as we continue to work on these features.
Before then, you can complete this short form to keep up to date with progress on these new features or to get involved in user testing.
The Code Editor is already being used by thousands of people each month. If you’d like to try it, you can get started writing code right in your browser today, with zero setup.
The post Introducing classroom management to the Code Editor appeared first on Raspberry Pi Foundation.
Young people taking part in the European Astro Pi Challenge are about to have their computer programs sent to the International Space Station (ISS). Astro Pi is run annually in collaboration by us and ESA Education, and offers two ways to get involved: Mission Zero and Mission Space Lab.
This year, over 25,000 young people from across Europe and eligible ESA Member States are getting their programs ‘uplinked’ to the Astro Pi computers aboard the ISS, where they will be running over the next few weeks.
Mission Zero is an exciting activity for kids with little or no experience with coding. We invite young people to create a Python program that displays an 8×8 pixel image or animation. This program then gets sent to the ISS, and each pixel art piece is displayed for 30 seconds on the LED matrix display of the Astro Pi computers on the ISS.
We picked the theme ‘fauna and flora’ as the inspiration for young people’s pixel art, as it proved so popular last year, and we weren’t disappointed: this year, 24,378 young people submitted 16,039 Mission Zero creations!
We’ve tested every program and are pleased to announce that 15,942 Mission Zero programs will be sent to run on the ISS from mid May.
Once again, we have been amazed at the wonderful images and animations that young people have created. Seeing all the images that have been submitted is one of the most enjoyable and inspiring things to do as we work on the Astro Pi Challenge. Here is a little selection of some of our favourites submitted this year:
For Mission Space Lab, we invite more experienced young coders to take on a scientific challenge: to calculate the speed that the ISS orbits Earth.
Teams are tasked with writing a program that uses the Astro Pis’ sensors and visible light camera to capture data for their calculations, and we have really enjoyed seeing the different approaches the teams have taken.
Some teams decided to calculate the distance between two points in photos of the Earth’s surface and combine this with how long it took for the ISS to pass over the points to find the speed. This particular method uses feature extraction and needs to account for ground sampling distance — how many square metres are represented in one pixel in an image of the ground taken from above — to get an accurate output.
We’ve also seen teams use data from the gyroscope to calculate the speed using the angle readings and photos to get their outputs. Yet other teams have derived the speed using equations of motion and sampling from the accelerometer.
All teams that took multiple samples from the Astro Pi sensors, or multiple images, had to decide how to output a final estimate for the speed of the ISS. Most teams opted to use the mean average. But a few teams chose to filter their samples to choose only the ‘best’ ones based on prior knowledge (Bayesian filtering), and some used a machine learning model and the Astro Pi’s machine learning dongle to select which images or data samples to use. Some teams even provided a certainty score along with their final estimate.
However the team choses to approach the challenge, before their program can run on the ISS, we need to make sure of a few things. For a start, we check that they’ve followed the challenge rules and meet the ISS security requirements. Next, we check that the program can run without errors on the Astro Pis as the astronauts on board the ISS can’t stop what they’re doing to fix any problems.
So, all programs submitted to us must pass a rigorous testing process before they can be sent into space. We run each program on several replica Astro Pis, then run all the programs sequentially, to ensure there’s no problems. If the program passes testing, it’s awarded ‘flight status’ and can be sent to run in space.
This year, 236 teams have been awarded flight status. These teams represent 889 young people from 22 countries in Europe and ESA member states. The average age of these young people is 15, and 27% of them are girls. The UK has the most teams achieving flight status (61), followed by the Czech Republic (23) and Romania (22). You can see how this compares to last year and explore other breakdowns of participant data in the annual Astro Pi impact report.
Our congratulations to all the Mission Space Lab teams who’ve been awarded flight status: it is a great achievement. All these teams will be invited to join a live online Q&A with an ESA astronaut in June. We can’t wait to see what questions you send us for the astronaut.
Normally, the Astro Pi programs run continuously from the end of April until the end of May. However, this year, there is an interesting event happening in the skies above us that means that programs will pause for a few days. The ISS will be moving its position on the ‘beta angle’ and pivoting its orientation to maximise the sunlight that it can capture with its solar panels.
The ISS normally takes 90 minutes to complete its orbit, 45 minutes of which is in sunlight, and 45 minutes in darkness. When it moves along the beta angle, it will be in continual sunlight, allowing it to capture lots of solar energy and recharge its batteries. While in its new orientation, the ISS is exposed to increased heat from the sun so the window shutters must be closed to help the astronauts stay cool. That means taking photos of the Earth’s surface won’t be possible for a few days.
Once all of the programs have run, we will send the Mission Space Lab teams the data collected during their experiments. All successful Mission Zero and Mission Space Lab teams and mentors will also receive personal certificates to recognise their mission completion.
Congratulations to all of this year’s Astro Pi Challenge participants, and especially to all successful teams.
The post Young people’s Astro Pi code is sent to the International Space Station appeared first on Raspberry Pi Foundation.
Educators around the world are grappling with the problem of whether to use artificial intelligence (AI) tools in the classroom. As more and more teachers start exploring the ways to use these tools for teaching and learning computing, there is an urgent need to understand the impact of their use to make sure they do not exacerbate the digital divide and leave some students behind.
Sri Yash Tadimalla from the University of North Carolina and Dr Mary Lou Maher, Director of Research Community Initiatives at the Computing Research Association, are exploring how student identities affect their interaction with AI tools and their perceptions of the use of AI tools. They presented findings from two of their research projects in our March seminar.
A common approach in research is to begin with a preliminary study involving a small group of participants in order to test a hypothesis, ways of collecting data from participants, and an intervention. Yash explained that this was the approach they took with a group of 25 undergraduate students on an introductory Java programming course. The research observed the students as they performed a set of programming tasks using an AI chatbot tool (ChatGPT) or an AI code generator tool (GitHub Copilot).
The data analysis uncovered five emergent attitudes of students using AI tools to complete programming tasks:
Whether these attitudes are common for other and larger groups of students requires more research. However, these preliminary groupings may be useful for educators who want to understand their students and how to support them with targeted instructional techniques. For example, highly confident students may need encouragement to check the accuracy of AI-generated code, while frustrated students may need assistance to use the AI tools to complete programming tasks.
Yash and Mary Lou explained that their next research study took an intersectional approach to student identity. Intersectionality is a way of exploring identity using more than one defining characteristic, such as ethnicity and gender, or education and class. Intersectional approaches acknowledge that a person’s experiences are shaped by the combination of their identity characteristics, which can sometimes confer multiple privileges or lead to multiple disadvantages.
In the second research study, 50 undergraduate students participated in programming tasks and their approaches and attitudes were observed. The gathered data was analysed using intersectional groupings, such as:
Although the researchers observed differences amongst the groups of students, there was not enough data to determine whether these differences were statistically significant.
Participating students were also asked about their views on using AI tools, such as “Did having AI help you in the process of programming?” and “Does your experience with using this AI tool motivate you to continue learning more about programming?”
The same intersectional approach was taken towards analysing students’ answers. One surprising finding stood out: when asked whether using AI tools to help with programming tasks should be considered cheating, students from more privileged backgrounds agreed that this was true, whilst students with less privilege disagreed and said it was not cheating.
This finding is only with a very small group of students at a single university, but Yash and Mary Lou called for other researchers to replicate this study with other groups of students to investigate further.
You can watch the full seminar here:
As researchers and educators, we often hear that we should educate students about the importance of making AI ethical, fair, and accessible to everyone. However, simply hearing this message isn’t the same as truly believing it. If students’ identities influence how they view the use of AI tools, it could affect how they engage with these tools for learning. Without recognising these differences, we risk continuing to create wider and deeper digital divides.
The focus of our ongoing seminar series is on teaching programming with or without AI.
For our next seminar on Tuesday 16 April at 17:00 to 18:30 GMT, we’re joined by Brett A. Becker (University College Dublin), who will talk about how generative AI can be used effectively in secondary school programming education and how it can be leveraged so that students can be best prepared for continuing their education or beginning their careers. To take part in the seminar, click the button below to sign up, and we will send you information about how to join. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our blog and on the previous seminars and recordings page.
The post Insights into students’ attitudes to using AI tools in programming education appeared first on Raspberry Pi Foundation.
AI models for general-purpose programming, such as OpenAI Codex, which powers the AI pair programming tool GitHub Copilot, have the potential to significantly impact how we teach and learn programming.
The basis of these tools is a ‘natural language to code’ approach, also called natural language programming. This allows users to generate code using a simple text-based prompt, such as “Write a simple Python script for a number guessing game”. Programming-specific AI models are trained on vast quantities of text data, including GitHub repositories, to enable users to quickly solve coding problems using natural language.
As a computing educator, you might ask what the potential is for using these tools in your classroom. In our latest research seminar, Majeed Kazemitabaar (University of Toronto) shared his work in developing AI-assisted coding tools to support students during Python programming tasks.
Majeed argued that natural language programming can enable students to focus on the problem-solving aspects of computing, and support them in fixing and debugging their code. However, he cautioned that students might become overdependent on the use of ‘AI assistants’ and that they might not understand what code is being outputted. Nonetheless, Majeed and colleagues were interested in exploring the impact of these code generators on students who are starting to learn programming.
In one study, the team Majeed works in investigated whether students’ task and learning performance was affected by an AI code generator. They split 69 students (aged 10–17) into two groups: one group used a code generator in an environment, Coding Steps, that enabled log data to be captured, and the other group did not use the code generator.
Learners who used the code generator completed significantly more authoring tasks — where students manually write all of the code — and spent less time completing them, as well as generating significantly more correct solutions. In multiple choice questions and modifying tasks — where students were asked to modify a working program — students performed similarly whether they had access to the code generator or not.
A test was administered a week later to check the groups’ performance, and both groups did similarly well. However, the ‘code generator’ group made significantly more errors in authoring tasks where no starter code was given.
Majeed’s team concluded that using the code generator significantly increased the completion rate of tasks and student performance (i.e. correctness) when authoring code, and that using code generators did not lead to decreased performance when manually modifying code.
Finally, students in the code generator group reported feeling less stressed and more eager to continue programming at the end of the study.
In a related study, Majeed and his colleagues investigated how novice programmers used the code generator and whether this usage impacted their learning. Working with data from 33 learners (aged 11–17), they analysed 45 tasks completed by students to understand:
Their analysis found that students used the code generator for the majority of task attempts (74% of cases) with far fewer tasks attempted without the code generator (26%). Of the task attempts made using the code generator, 61% involved a single prompt while only 8% involved decomposition of the task into multiple prompts for the code generator to solve subgoals; 25% used a hybrid approach — that is, some subgoal solutions being AI-generated and others manually written.
In a comparison of students against their post-test evaluation scores, there were positive though not statistically significant trends for students who used a hybrid approach (see the image below). Conversely, negative though not statistically significant trends were found for students who used a single prompt approach.
Though not statistically significant, these results suggest that the students who actively engaged with tasks — i.e. generating some subgoal solutions, manually writing others, and debugging their own written code — performed better in coding tasks.
Majeed concluded that while the data showed evidence of self-regulation, such as students writing code manually or adding to AI-generated code, students frequently used the output from single prompts in their solutions, indicating an over-reliance on the output of AI code generators.
He suggested that teachers should support novice programmers to write better quality prompts to produce better code.
If you want to learn more, you can watch Majeed’s seminar:
You can read more about Majeed’s work on his personal website. You can also download and use the code generator Coding Steps yourself.
The focus of our ongoing seminar series is on teaching programming with or without AI.
For our next seminar on Tuesday 16 April at 17:00–18:30 GMT, we’re joined by Brett Becker (University College Dublin), who will discuss how generative AI may be effectively utilised in secondary school programming education and how it can be leveraged so that students can be best prepared for whatever lies ahead. To take part in the seminar, click the button below to sign up, and we will send you information about joining. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars and recordings page.
The post Using an AI code generator with school-age beginner programmers appeared first on Raspberry Pi Foundation.
The use of generative AI tools (e.g. ChatGPT) in education is now common among young people (see data from the UK’s Ofcom regulator). As a computing educator or researcher, you might wonder what impact generative AI tools will have on how young people learn programming. In our latest research seminar, Barbara Ericson and Xinying Hou (University of Michigan) shared insights into this topic. They presented recent studies with university student participants on using generative AI tools based on large language models (LLMs) during programming tasks.
Barbara and Xinying started their seminar with an overview of their earlier research into using Parson’s Problems to scaffold university students as they learn to program. Parson’s Problems (PPs) are a type of code completion problem where learners are given all the correct code to solve the coding task, but the individual lines are broken up into blocks and shown in the wrong order (Parsons and Haden, 2006). Distractor blocks, which are incorrect versions of some or all of the lines of code (i.e. versions with syntax or semantic errors), can also be included. This means to solve a PP, learners need to select the correct blocks as well as place them in the correct order.
In one study, the research team asked whether PPs could support university students who are struggling to complete write-code tasks. In the tasks, the 11 study participants had the option to generate a PP when they encountered a challenge trying to write code from scratch, in order to help them arrive at the complete code solution. The PPs acted as scaffolding for participants who got stuck trying to write code. Solutions used in the generated PPs were derived from past student solutions collected during previous university courses. The study had promising results: participants said the PPs were helpful in completing the write-code problems, and 6 participants stated that the PPs lowered the difficulty of the problem and speeded up the problem-solving process, reducing their debugging time. Additionally, participants said that the PPs prompted them to think more deeply.
This study provided further evidence that PPs can be useful in supporting students and keeping them engaged when writing code. However, some participants still had difficulty arriving at the correct code solution, even when prompted with a PP as support. The research team thinks that a possible reason for this could be that only one solution was given to the PP, the same one for all participants. Therefore, participants with a different approach in mind would likely have experienced a higher cognitive demand and would not have found that particular PP useful.
To understand the impact of using PPs with different learners, the team then undertook a follow-up study asking whether PPs could specifically support students with lower computer science self-efficacy. The results show that study participants with low self-efficacy who were scaffolded with PPs support showed significantly higher practice performance and higher problem-solving efficiency compared to participants who had no scaffolding. These findings provide evidence that PPs can create a more supportive environment, particularly for students who have lower self-efficacy or difficulty solving code writing problems. Another finding was that participants with low self-efficacy were more likely to completely solve the PPs, whereas participants with higher self-efficacy only scanned or partly solved the PPs, indicating that scaffolding in the form of PPs may be redundant for some students.
These two studies highlighted instances where PPs are more or less relevant depending on a student’s level of expertise or self-efficacy. In addition, the best PP to solve may differ from one student to another, and so having the same PP for all students to solve may be a limitation. This prompted the team to conduct their most recent study to ask how large language models (LLMs) can be leveraged to support students in code-writing practice without hindering their learning.
This recent third study focused on the development of CodeTailor, a tool that uses LLMs to generate and evaluate code solutions before generating personalised PPs to scaffold students writing code. Students are encouraged to engage actively with solving problems as, unlike other AI-assisted coding tools that merely output a correct code correct solution, students must actively construct solutions using personalised PPs. The researchers were interested in whether CodeTailor could better support students to actively engage in code-writing.
In a study with 18 undergraduate students, they found that CodeTailor could generate correct solutions based on students’ incorrect code. The CodeTailor-generated solutions were more closely aligned with students’ incorrect code than common previous student solutions were. The researchers also found that most participants (88%) preferred CodeTailor to other AI-assisted coding tools when engaging with code-writing tasks. As the correct solution in CodeTailor is generated based on individual students’ existing strategy, this boosted students’ confidence in their current ideas and progress during their practice. However, some students still reported challenges around solution comprehension, potentially due to CodeTailor not providing sufficient explanation for the details in the individual code blocks of the solution to the PP. The researchers argue that text explanations could help students fully understand a program’s components, objectives, and structure.
In future studies, the team is keen to evaluate a design of CodeTailor that generates multiple levels of natural language explanations, i.e. provides personalised explanations accompanying the PPs. They also aim to investigate the use of LLM-based AI tools to generate a self-reflection question structure that students can fill in to extend their reasoning about the solution to the PP.
Barbara and Xinying’s seminar is available to watch here:
Find examples of PPs embedded in free interactive ebooks that Barbara and her team have developed over the years, including CSAwesome and Python for Everybody. You can also read more about the CodeTailor platform in Barbara and Xinying’s paper.
The focus of our ongoing seminar series is on teaching programming with or without AI.
For our next seminar on Tuesday 12 March at 17:00–18:30 GMT, we’re joined by Yash Tadimalla and Prof. Mary Lou Maher (University of North Carolina at Charlotte). The two of them will share further insights into the impact of AI tools on the student experience in programming courses. To take part in the seminar, click the button below to sign up, and we will send you information about joining. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars and recordings page.
The post Supporting learners with programming tasks through AI-generated Parson’s Problems appeared first on Raspberry Pi Foundation.
How do you best teach programming in school? It’s one of the core questions for primary and secondary computing teachers. That’s why we’re making it the focus of our free online seminars in 2024. You’re invited to attend and hear about the newest research about the teaching and learning of programming, with or without AI tools.
Building on the success and the friendly, accessible session format of our previous seminars, this coming year we will delve into the latest trends and innovative approaches to programming education in school.
Our monthly online seminars are not only for computing educators but also for everyone else who is passionate about teaching young people to program computers. The seminar participants are a diverse community of teachers, technology enthusiasts, industry professionals, coding club volunteers, and researchers.
With the seminars we aim to bridge the gap between the newest research and practical teaching. Whether you are an educator in a traditional classroom setting or a mentor guiding learners in a CoderDojo or Code Club, you will gain insights from leading researchers about how school-age learners engage with programming.
Each online seminar begins with an expert presenter delivering their latest research findings in an accessible way. We then move into small groups to encourage discussion and idea exchange. Finally, we come back together for a Q&A session with the presenter.
Here’s what attendees had to say about our previous seminars:
“As a first-time attendee of your seminars, I was impressed by the welcoming atmosphere.”
“[…] several seminars (including this one) provided valuable insights into different approaches to teaching computing and technology.”
“I plan to use what I have learned in the creation of curriculum […] and will pass on what I learned to my team.”
“I enjoyed the fact that there were people from different countries and we had a chance to see what happens elsewhere and how that may be similar and different to what we do here.”
Computing teachers know that, for some students, learning about the syntax of programming languages is very challenging. Working through Parson’s Problem activities can be a way for students to learn to make sense of the order of lines of code and how syntax is organised. But for teachers it can be hard to precisely diagnose their students’ misunderstandings, which in turn makes it hard to create activities that address these misunderstandings.
At our first 2024 seminar on 9 January, Dr Barbara Ericson and Xinying Hou (University of Michigan) will present a promising new approach to helping teachers solve this difficulty. In one of their studies, they combined Parsons Problems and generative AI to create targeted activities for students based on the errors students had made in previous tasks. Thus they were able to provide personalised activities that directly addressed gaps in the students’ learning.
All our seminars start at 17:00 UK time (18:00 CET / 12:00 noon ET / 9:00 PT) and are held online on Zoom. To ensure you don’t miss out, sign up now to receive calendar invitations, and access links for each seminar on the day.
If you sign up today, we’ll also invite you to our 12 December seminar with Anaclara Gerosa (University of Glasgow) about how to design and structure of computing activities for young learners, the final session in our 2023 series about primary (K-5) computing education.
The post Spotlight on teaching programming with and without AI in our 2024 seminar series appeared first on Raspberry Pi Foundation.
We all know that learning to program, and specifically learning how to debug or fix code, can be frustrating and leave beginners overwhelmed and disheartened. In a recent blog article, our PhD student Lauria at the Raspberry Pi Computing Education Research Centre highlighted the pivotal role that teachers play in shaping students’ attitudes towards debugging. But what about teachers who are coding novices themselves?
In many countries, primary school teachers are holistic educators and often find themselves teaching computing despite having little or no experience in the field. In a recent seminar of our series on computing education for primary-aged children, Luisa Greifenstein told attendees that struggling with debugging and negative attitudes towards programming were among the top ten challenges mentioned by teachers.
Luisa is a researcher at the University of Passau, Germany, and has been working closely with both teacher trainees and experienced primary school teachers in Germany. She’s found that giving feedback to students can be difficult for primary school teachers, and especially for teacher trainees, as programming is still new to them. Luisa’s seminar introduced a tool to help.
To address this issue, the University of Passau has initiated the primary::programming project. One of its flagship tools, LitterBox, offers a unique solution to debugging and is specifically designed for Scratch, a beginners’ programming language widely used in primary schools.
LitterBox serves as a static code debugging tool that transforms code examination into an engaging experience. With a nod to the Scratch cat, the tool visualises the debugging of Scratch code as checking the ‘litterbox’, categorising issues into ‘bugs’ and ‘smells’:
What sets LitterBox apart is that it also rewards correct code by displaying ‘perfumes’. For instance, it will praise correct broadcasting or the use of custom blocks. For every identified problem or achievement, the tool provides short and direct feedback.
Luisa and her team conducted a study to gauge the effectiveness of LitterBox. In the study, teachers were given fictitious student code with bugs and were asked to first debug the code themselves and then explain in a manner appropriate to a student how to do the debugging.
The results were promising: teachers using LitterBox outperformed a control group with no access to the tool. However, the team also found that not all hints proved equally helpful. When hints lacked direct relevance to the code at hand, teachers found them confusing, which highlighted the importance of refining the tool’s feedback mechanisms.
Despite its limitations, LitterBox proved helpful in another important aspect of the teachers’ work: coding task creation. Novice students require structured tasks and help sheets when learning to code, and teachers often invest substantial time in developing these resources. While LitterBox does not guide educators in generating new tasks or adapting them to their students’ needs, in a second study conducted by Luisa’s team, teachers who had access to LitterBox not only received support in debugging their own code but also provided more scaffolding in task instructions they created for their students compared to teachers without LitterBox.
One important realisation that we had in the Q&A phase of Luisa’s seminar was that many different research teams are working on solutions for similar challenges, and that the impact of this research can be maximised by integrating new findings and resources. For instance, what the LitterBox tool cannot offer could be filled by:
As we navigate the evolving landscape of programming education, it’s clear that innovative tools like LitterBox can make a significant difference in the journey of both educators and students. By equipping educators with effective debugging and task creation solutions, we can create a more positive and engaging learning experience for students.
If you’re an educator, consider exploring how such tools can enhance your teaching and empower your students in their coding endeavours.
You can watch the recording of Luisa’s seminar here:
If you’re interested in the latest developments in computing education, join us at one of our free, monthly seminars. In these sessions, researchers from all over the world share their innovative ideas and are eager to discuss them with educators and students. In our December seminar, Anaclara Gerosa (University of Edinburgh) will share her findings about how to design and structure early-years computing activities.
This will be the final seminar in our series about primary computing education. Look out for news about the theme of our 2024 seminar series, which are coming soon.
The post Support for new computing teachers: A tool to find Scratch programming errors appeared first on Raspberry Pi Foundation.
A couple of months ago we announced that you can test the online text-based Code Editor we’re building to help young people aged 7 and older learn to write code. Now we’ve made the code for the Editor open source so people can repurpose and contribute to it.
You and your learners can try out the Code Editor in our Python project paths. We’ve included a feedback form for you to let us know what you think about the Editor.
Since the Editor lets learners save their code using their Raspberry Pi Foundation account, it’s easy for them to build on projects they’ve started in the classroom or at home, or bring a project they’ve started at home to their coding club.
Python is the first programming language our Code Editor supports because it’s popular in schools, CoderDojos, and Code Clubs, as well as in industry. We’ll soon be adding support for web development languages (HTML/CSS).
We know that starting out with new programming tools can be tricky and add to the cognitive load of learning new subject matter itself. That’s why our Editor has a simple and accessible user interface and design:
We’ll expand the Editor’s functionalities as we go. For example, at the moment we’re looking at how to improve the Editor’s user interface (UI) for better mobile support.
If there’s a feature you think would help the Editor become more accessible and more suitable for young learners, or make it better for your classroom or club, please let us know via the feedback form.
Our vision is that every young person develops the knowledge, skills, and confidence to use digital technologies effectively, and to be able to critically evaluate these technologies and confidently engage with technological change. We’re part of a global community that shares that vision, so we’ve made the Editor available as an open-source project. That means other projects and organisations focussed on helping people learn about coding and digital technologies can benefit from the work.
To support the widest possible range of learners, we’ve designed the Code Editor application to work well on constrained devices and low-bandwidth connections. Safeguarding, accessibility, and data privacy are also key considerations when we build digital products at the Foundation. That’s why we decided to design the front end of the Editor to work in a standalone capacity, with Python executed through Skulpt, an entirely in-browser implementation of Python, and code changes persisted in local storage by default. Learners have the option of using a Raspberry Pi Foundation account to save their work, with changes then persisted via calls to a back end application programming interface (API).
As safeguarding is always at the core of what we do, we only make features available that comply with our safeguarding policies as well as the ICO’s age-appropriate design code. We considered supporting functionality such as image uploads and code sharing, but at the time of writing have decided to not add these features given that, without proper moderation, they present risks to safeguarding.
There’s an amazing community developing a wealth of open-source libraries. We chose to build our text-editor interface using CodeMirror, which has out-of-the-box mobile and tablet support and includes various useful features such as syntax highlighting and keyboard shortcuts. This has enabled us to focus on building the best experience for learners, rather than reinventing the wheel.
Diving a bit more into the technical details:
You can find out more about our Editor’s code for both the UI front end and API back end in our GitHub readme and contributions documentation. These kick-starter docs will help you get up and running faster:
The Editor’s front end is licensed as permissively as possible under the Apache Licence 2.0, and we’ve chosen to license the back end under the copyleft AGPL V3 licence. Copyleft licences mean derived works must be licensed under the same terms, including making any derived projects also available to the community.
We’d greatly appreciate your support with developing the Editor further, which you can give by:
Our work to develop and publish the Code Editor as an open-source project has been funded by Endless. We thank them for their generous support.
If you are interested in partnering with us to fund this key work, or you are part of an organisation that would like to make use of the Code Editor, please reach out to us via email.
The post Our Code Editor is open source appeared first on Raspberry Pi Foundation.
We are building a new online text-based Code Editor to help young people aged 7 and older learn to write code. It’s free and designed for young people who attend Code Clubs and CoderDojos, students in schools, and learners at home.
At this stage of development, the Code Editor enables learners to:
We’ve chosen Python as the first programming language our Code Editor supports because it is popular in schools, CoderDojos, and Code Clubs. Many educators and young people like Python because they see it as similar to the English language. It is often the text-based language young people learn when they take their first steps away from a block-based programming environment, such as Scratch.
Python is also widely used by professional programmers and usually tops at least one of the industry-standard indexes that ranks programming languages.
We will be adding support for web development languages (HTML/CSS/JavaScript) to the Editor in the near future.
We’re also planning to add features such as project sharing and collaboration, which we know young people will love. We want the Editor to be safe, accessible, and age-appropriate. As safeguarding is always at the core of what we do, we’ll only make new features available once we’ve ensured they comply with the ICO’s age-appropriate design code and our safeguarding policies.
We are inviting you to test the Code Editor as part of what we call the beta phase of development. As the Editor is still in development, some things might not look or work as well as we’d like — and this is why we need your help.
We’d love you to try the Editor out and let us know what worked well for you, what didn’t work well, and what you’d like to see next.
You can now try out the Code Editor in the first two projects of our ‘Intro to Python’ path. We’ve included a feedback form for you to let us know which project you tried, and what you think of the Editor. We’d love to hear from you.
Your feedback helps us decide what to do next. Based on what learners, educators, volunteers, teachers, and parents tell us, we will make the improvements to the Editor that matter most to the young people we aim to support.
One of our long-term goals is to engage millions of young people in learning about computing and how to create with digital technologies. We’re developing the Code Editor with three main aims in mind.
We aim to build the Code Editor so it:
Our work on the Code Editor will:
We want to offer a Code Editor that:
We’re also planning on making the Editor available as an open source project so that other projects and organisations focussed on helping people learn to code can benefit. More on this soon.
Our work on the Code Editor has been generously funded by the Algorand Foundation and Endless, and we thank them for their generous support. If you are interested in partnering with us to fund this key work, please reach out to us via email.
The post Test our new Code Editor for young people appeared first on Raspberry Pi Foundation.
Every young learner needs a successful start to their learning journey in the primary computing classroom. One aspect of this for teachers is to introduce programming to their learners in a structured way. As computing education is introduced in more schools, the need for research-informed strategies and approaches to support beginner programmers is growing. Over recent years, researchers have proposed various strategies to guide teachers and students, such as the block model, PRIMM, and, in the case of this month’s seminar, TIPP&SEE.
We are committed to make computing and creating with digital technologies accessible to all young people, including through our work with educators and researchers. In our current online research seminar series, we focus on computing education for primary-aged children (K–5, ages 5 to 11). In the series’ second seminar, we were delighted to welcome Dr Jean Salac, researcher in the Code & Cognition Lab at the University of Washington.
Jean’s work sits across computing education and human-computer interaction, with an emphasis on justice-focused computing for youth. She talked to the seminar attendees about her work on developing strategies to support primary school students learning to program in Scratch. Specifically, Jean described an approach called TIPP&SEE and how teachers can use it to guide their learners through programming activities.
TIPP&SEE is a metacognitive approach for programming in Scratch. The purpose of metacognitive strategies is to help students become more aware of their own learning processes.
TIPP&SEE scaffolds students as they learn from example Scratch projects: TIPP (Title, Instructions, Purpose, Play) is a scaffold to read and run a Scratch project, while SEE (Sprites, Events, Explore) is a scaffold to examine projects more deeply and begin to adapt them.
TIPP&SEE is inspired by the work of Irene Lee and colleagues who proposed a progressive three-stage approach called Use-Modify-Create. Following that approach, learners move from reading pre-existing programs (“not mine”) to adapting and creating their own programs (“mine”) and gradually increase ownership of their learning.
Proponents of scaffolded approaches like Use-Modify-Create argue that engaging learners in cycles of using existing programs (e.g. worked examples) before they move to adapting and creating new programs encourages ownership and agency in learning. TIPP&SEE builds on this model by providing additional scaffolding measures to support learners.
Jean presented some promising results from her research on the use of TIPP&SEE in classrooms. In one study, fourth-grade learners (age 9 to 10) were randomly assigned to one of two groups: (i) Use-Modify-Create only (the control group) or (ii) Use-Modify-Create with TIPP&SEE. Jean found that, compared to learners in the control group, learners in the TIPP&SEE group:
In another study, Jean compared how learners in the TIPP&SEE and control groups performed on several cognitive tests. She found that, in the TIPP&SEE group, students with learning difficulties performed as well as students without learning difficulties. In other words, in the TIPP&SEE group the performance gap was much narrower than in the control group. In our seminar, Jean argued that this indicates the TIPP&SEE scaffolding provides much-needed support to diverse groups of students.
TIPP&SEE is a multi-step strategy where learners start by looking at the surface elements of a program, and then move on to examining the underlying code. In the TIPP phase, learners first read the title and instructions of a Scratch project, identify its purpose, and then play the project to see what it does.
In the second phase, SEE, learners look inside the Scratch project to click on sprites and predict what each script is doing. They then make changes to the Scratch code and see how the project’s output changes. By changing parameters, learners can observe which part of the output changes as a result and then reason how each block functions. This practice is called deliberate tinkering because it encourages learners to observe changes while executing programs multiple times with different parameters.
You can read more of Jean’s research on TIPP&SEE on her website. There’s also a video on how TIPP&SEE can be used, and free lesson resources based on TIPP&SEE are available in Elementary Computing for ALL and Scratch Encore.
Jean’s talk highlighted the need for computing to be inclusive and to give equitable access to all learners. The field of computing education is still in its infancy, though our understanding of how young people learn about computing is growing. We ourselves work to deepen our understanding of how young people learn through computing and digital making experiences.
In our own research, we have been investigating similar teaching approaches for programming, including the use of the PRIMM approach in the UK, so we were very interested to learn about different approaches and country contexts. We are grateful to Dr Jean Salac for sharing her work with researchers and teachers alike. Watch the recording of Jean’s seminar to hear more:
If you are looking for more free resources to help you structure your computing lessons:
In the next seminar of our online series on primary computing, I will be presenting my research on integrated computing and literacy activities. Sign up now to join us for this session on Tues 7 March:
As always, the seminars will take place online on the first Tuesday of the month at 17:00–18:30 UK time. Hope to see you there!
The post Supporting beginner programmers in primary school using TIPP-SEE appeared first on Raspberry Pi Foundation.
We are so excited to share another story from the community! Our series of community stories takes you across the world to hear from young people and educators who are engaging with creating digital technologies in their own personal ways.
In this story we introduce you to Selin, a digital maker from Istanbul, Turkey, who is passionate about robotics and AI. Watch the video to hear how Selin’s childhood pet inspired her to build tech projects that aim to help others live well.
Selin (16) started her digital making journey because she wanted to solve a problem: after her family’s beloved dog Korsan passed away, she wanted to bring him back to life. Selin thought a robotic dog could be the answer, and so she started to design her project on paper. When she found out that learning to code would mean she could actually make a robotic dog, Selin began to teach herself about coding and digital making.
Thanks to her local CoderDojo, which is part of the worldwide CoderDojo network of free, community-based, volunteer-led programming clubs where young people explore digital technology, Selin’s interest in creating tech projects grew and grew. Selin has since built seven robots, and her enthusiasm for building things with digital technology shows no sign of stopping.
One of Selin’s big motivations to explore digital making was having an event to work towards. At her Dojo, Selin found out about Coolest Projects, the global technology showcase for young people. She then set herself the task of making a robot to present at the Coolest Projects event in 2018.
When thinking about ideas for what to make for Coolest Projects, Selin remembered how it felt to lose her dog. She wondered what it must be like when a blind person’s guide dog passes away, as that person loses their friend as well as their support. So Selin decided to make a robotic guide dog called IC4U. She contacted several guide dog organisations to find out how guide dogs are trained and what they need to be able to do so she could replicate their behaviour in her robot. The robot is voice-controlled so that people with impaired sight can interact with it easily.
Selin and her parents travelled to Coolest Projects International in Dublin, thanks to support from the CoderDojo Foundation. Accompanying them was Selin’s project IC4U, which became a judges’ favourite in the Hardware category. Selin enjoyed participating in Coolest Projects so much that she started designing her project for next year’s event straight away:
“When I returned back I immediately started working for next year’s Coolest Projects.”
Selin
Many of Selin’s tech projects share a theme: to help make the world a better place. For example, another robot made by Selin is the BB4All — a school assistant robot to tackle bullying. And last year, while she attended the Stanford AI4ALL summer camp, Selin worked with a group of young people to design a tech project to increase the speed and accuracy of lung cancer diagnoses.
Through her digital making projects, Selin wants to show how people can use robotics and AI technology to support people and their well-being. In 2021, Selin’s commitment to making these projects was recognised when she was awarded the Aspiring Teen Award by Women in Tech.
Listening to Selin, it is inspiring to hear how a person can use technology to express themselves as well as create projects that have the potential to do so much good. Selin acknowledges that sometimes the first steps can be the hardest, especially for girls interested in tech: “I know it’s hard to start at first, but interests are gender-free.”
“Be curious and courageous, and never let setbacks stop you so you can actually accomplish your dream.”
Selin
We have loved seeing all the wonderful projects that Selin has made in the years since she first designed a robot dog on paper. And it’s especially cool to see that Selin has also continued to work on her robot IC4U, the original project that led her to coding, Coolest Projects, and more. Selin’s robot has developed with its maker, and we can’t wait to see what they both go on to do next.
Help us celebrate Selin and inspire other young people to discover coding and digital making as a passion, by sharing her story on Twitter, LinkedIn, and Facebook.
The post Celebrating the community: Selin appeared first on Raspberry Pi.
A year ago we launched our Introduction to Scratch path of six new coding projects. This was the first path to use our new 3…2…1…Make! approach for prioritising fun and engagement whilst enabling creators to make the things that matter to them. Creators learn how to add code, costumes, and sounds to sprites as they make animations, a game, an app, and a book.
As the first birthday of the Introduction to Scratch path approached, we decided to review and refresh each project. We used input from the community, looked at remixes of the projects, and analysed visitor data to guide us in our review.
We would like to say a massive thank you to everyone who engaged in focus groups, provided input via social channels, or clicked the project feedback buttons. We really appreciate you taking the time to reach out and we hope you will be pleased with the changes.
The updates are split into two parts, those we made specifically to the Introduction to Scratch path, and changes made across all of the 3…2…1…Make! projects.
The first thing you might notice is the revamp of our Introduction step, now called ‘You will make’. This simplified step focuses on setting the scene and encourages creators to play with a completed project example.
Also changed is the Reflection step, replaced by ‘Quick quiz’ — a much neater page that guides creators through three questions before awarding a project badge.
Here is an overview of the Scratch path to tell you more about the projects and the changes we’ve made to the content.
Creators can start using the updated Scratch projects right away!
Our first three projects in the path introduce creators to a set of skills and provide step-by-step instructions to help them develop initial confidence.
In this project, creators design a space scene with characters that emote to share their thoughts or feelings. We received some amazing feedback from a member of the Deaf community to enhance the Nano uses sign language task and include a great new boxout to prompt discussion amongst our creators.
We also heard from a couple of club leaders that the Text to Speech extension in Scratch was a great addition to this project so we added an optional Text to Speech information card to the Upgrade your project step.
The bus in the Catch the bus project is a tour bus, but we originally used the school backdrop as a departure point. We liked how the backdrop looked but now recognise that doing a project about a school bus whilst in a club was probably not the most popular choice. Please forgive us! The project now uses a nighttime city scene.
We also removed the use of the ‘Timer hat block’ from this project — it isn’t needed for the rest of the path and has behaviour that complicates things. The ‘timer hat block’ has been replaced by a ‘wait block’.
We have loved engaging with the community submissions of this project and really enjoyed seeing how quickly we can find the small bugs on each level of the games that have been created. With replicating that enthusiasm in mind, our changes to this project focused on young creators sharing their project and playing projects created by others.
Our new Share and play step has a number of options, including sharing in a club, submitting your project to a shared studio, and experiencing remixes as a user. We have also embedded some community projects into the step to provide upgrade ideas and inspiration.
The next two projects in the path encourage creators to practise the skills they learned in the previous ‘Explore’ projects, and to express themselves creatively while they grow in independence.
The revamped Get ideas task on the first step of each Design project now has a featured community project that will be regularly updated. You may also notice that the inspirational examples have been reordered or changed using analysis from interactions with them.
Additional community submissions can be found in the Share and play steps to provide upgrade ideas and creators are encouraged to look at remixes of the starter project for even more inspiration.
Interacting with remixes of the Silly eyes project is one of our favourite things to do! The project involves creating a character whose eyes follow the mouse pointer. We love seeing how design decisions have shaped each project and how various upgrades have been used.
For this project, we decided to remove the ‘Add stage effects’ step as it was largely a repeat of the earlier ‘Add sprite effects’ step. Stage effects is now an optional upgrade which means creators can get through to the ‘Share and play’ step to look at the design decisions made by others, then use those to choose which ideas to include in their project.
This project consists of creating an animation of a story. We looked at the remixes so far and realised the main steps of the surprise animations were:
Sometimes projects had a reaction in them but others relied on creating a reaction in the user watching the animation. With this in mind we moved the Reaction step and added it as an optional upgrade. We also added graphics to each step to explain the step position in the animation timeline.
A new option to remix one of the example projects was added to this project as a starting point if creators were short of time, needed help with ideas, or had perhaps already thought of an extension to the example animations.
Our final project in the path is where creators use their skills to meet a project brief for a particular audience.
The project brief has been revamped to make it more concise with the Reflection step becoming a checklist to keep track of how the project is meeting the brief.
This project consists of creating a book with multiple pages to tell a story or share facts. The major change to this project is a reorganisation of the steps. The original planning step has now split in two — the first step to decide the high-level purpose and audience for the book and the second step to plan the book in more detail using either the starter Scratch project or our new planning sheet.
The build and test step has also been restructured to break up the skills into categories and make the tasks clearer. At the end of the step, creators are encouraged to ask for feedback then repeat the process to work on their book until it is ready to share.
We will start refreshing another path soon but in the meantime, we hope you and your creators enjoy using the revamped Introduction to Scratch path. We would love to hear your feedback on any of our projects via the feedback button on the bottom of each project page.
We look forward to seeing what your creators make.
The post Introduce young people to coding with our updated projects appeared first on Raspberry Pi.
Launched in 2013, Hour of Code is an initiative to introduce young people to computer science using fun one-hour tutorials. To date, over 100 million young people have completed an hour of code with it.
Although the Hour of Code website is accessible all year round, every December for Computer Science Education Week people worldwide run their own Hour of Code events. Each year we love seeing many Code Clubs, CoderDojos, and young people at home across the community complete their Hour of Code. You can register your 2022 Hour of Code event now to run between 5 and 11 December.
To support your event, we have pulled together a bumper set of our free coding projects, which can each be completed in just one hour. You will find these activities on the Hour of Code website.
There’s something for all ages and levels of experience, so put an hour aside and help young people make something fabulous with code:
For younger creators new to coding, a Scratch project is a great place to start.
With our Space talk project, they can create a space scene with characters that ‘emote’ to share their thoughts or feelings using sounds, colours, and actions. Creators program the character emotes using Scratch blocks to control graphic effects, costume animation, and sound effects.
Alternatively, our Stress ball project lets them code an onscreen stress ball that reacts to user clicks. Creators use the Paint and Sound editors in Scratch to personalise a clickable stress ball, and they add Scratch blocks to control graphic effects, costume animation, and sound effects.
We love this fun stress ball example sent to us recently by young creator April from the United States:
Another great option is to use Code Club World, which is a free tool to help children who are new to coding.
For 7- to 11-year-olds who are more comfortable with block-based coding, our project Broadcasting spells is ideal to choose. With the project, they connect Scratch blocks to code a wand that casts spells turning sprites into toads, and growing and shrinking them. Creators use broadcast blocks to transform multiple sprites at once, and they create sound effects with the Sound editor in Scratch.
We have three exciting projects for trying text-based coding during Hour of Code in this category. The first, Anime expressions, is one of our brand-new ‘Introduction to web development’ projects. With this project, young people create a responsive webpage with text and images for an anime drawing tutorial. They write HTML to structure the webpage and CSS styles to apply layout, colour palettes, and fonts.
For a great introduction to coding with Python, we have the project Hello world from our ‘Introduction to Python’ path. With this project, creators write Python text-based code to create an interactive program that shows text and emojis based on user input. They learn about variables as they use them to store text and numbers, and they learn about writing functions to organise code and do calculations, retrieve the current date and time, and make a customisable dice.
LED firefly is a fantastic physical making project in which young people use a Raspberry Pi Pico microcontroller and basic electronic components to create a blinking LED firefly. They program the LED’s light patterns with MicroPython code and activate it via a switch they make themselves using jumper wires.
For 11- to 14-year-olds who are already comfortable with HTML, the Flip treat webcards project is a fun option. With this, they create a webpage showing a set of cards that flip when a visitor’s mouse pointer hovers over them. Creators use CSS styling and animations to add interactivity, then they customise the cards with fancy fonts and colour gradients.
Young people who have already done some Python coding can try out our project Target practice. With this project they create a game, using the p5 graphics library to draw a colourful target, and writing code so that the player scores points by hitting the target’s rings with arrows. While they create the project, they learn about RGB colours, shape positioning with x and y coordinates, and decisions using if, else-if, and else code statements.
Our project Charting champions is a great introduction to data visualisation and analysis for coders aged 15 and older. With the project, they will discover the power of the Python programming language as they store Olympic medal data in lists and use the pygal library to create an interactive chart.
Teenage coders who feel comfortable with Python programming can use our project Solar system simulator to code an animated, interactive solar system model using the Python p5 graphics library. Their model will be interactive, as they’ll use dictionaries to store planet facts that display when a user clicks on an orbiting planet.
Now is the time to register your Hour of Code event, then decide which project you’d like to support young people to create. You can download certificates for each of the creators from the Hour of Code certificates page.
And make sure to check out our project paths so you know what projects you can help the young people you support to code beyond this one hour of code.
We don’t just create activities so that other people can experience coding and digital making — we also get involved ourselves!
Recently, our teams who support the Code Club and CoderDojo networks got together to make LED fireflies. We are excited to get coding again as part of Hour of Code and Computer Science Education Week.
The post Take part in the Hour of Code appeared first on Raspberry Pi.
With our new free ‘Introduction to web development’ path, young people are able to learn HTML and create their own webpages on topics that matter to them. The path is made up of six projects that show children and teenagers how to structure pages using HTML, and style them using CSS.
Webpage creation has come a long way since the 1990s, but HTML is still the markup language that is used to display almost every page on the World Wide Web. By knowing how it works, you can deepen your understanding of the technology you use every day.
If you want to build your own website today, there are many tools to get you quickly up and running. These tools often involve dragging and dropping predefined elements and choosing from a wide collection of themed looks. Learning HTML and CSS skills is important for web designers, developers, and content creators who want to build unique webpage designs that make their content stand out.
With our new ‘Introduction to web development’ path, we want creators (the young people who use our projects) to be able to quickly make fantastic-looking websites that follow modern best practices, while they also learn how HTML and CSS work together to create a webpage. Creators write their own HTML to develop the content and structure of their webpages. And they customise our pre-built CSS style sheets to get their webpages to look like they imagine.
This really is a fun and unique approach to learning HTML and building a webpage, and we think young people will quickly engage with it. They start by finding out how to structure pages using HTML before applying CSS styles that bring their pages to life. Through the six projects, they build all the skills and independence they need to make webpages that matter to them.
We believe that young people should find out about website accessibility right from the start of their learning journey. That’s why the path for learning HTML shows creators how they can make their websites accessible to all their users regardless of the users’ needs or digital devices.
That’s why our new path uses semantic HTML. Older HTML tutorials might show you how to structure a webpage using tags like <div> and <span>. In contrast, the meaning and purpose of tags in semantic HTML is very clear. For example:
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
<main> is used to tag the main content for the webpage<footer> is used for content to be displayed in the footer<blockquote> contains a quote and typically the author of the quote<section> contains a portion of content that usually sits within the main part of the webpageSemantic HTML supports accessibility because it allows people who use a screen reader to more easily navigate a webpage and read it in a logical way.
Another element of accessible design that the path introduces is the colour combinations used on webpages. It is really important that contrasting colours are used for the background and the text. High contrast makes the text more readable, which means the webpage is more suitable for visually impaired users.
The path also shows creators the importance of adding meaningful alternative text for images. Good alternative text helps visually impaired users, and users who have a very low bandwidth and therefore turn images off in their web browser.
Finally, our path for learning HTML introduces creators to the concept of responsive web design. Responsive design is helpful because websites can be viewed on thousands of different devices. Some people view pages on large, high-resolution monitors, and others view them on a mobile phone screen. We show learners how they can use HTML and CSS to make their pages responsive so they display in the way that works best for the specific screen on which a user is viewing them.
We have written the projects in this path with young people of around the age from 9 to 17 in mind.
HTML and CSS are text-based markup languages. This means a young person who wants to start learning HTML needs to be familiar with typing on a keyboard. It would also be helpful to have experience of using the copy and paste function, which is useful when changing the layout of a page or copying similar pieces of code.
If a young person is unsure whether they have the right skills to get started with the path, they can first try out a short ‘Discover’ project. With this Discover project, young people can choose between the themes ‘space’, ‘sunsets’, ‘forests’, or ‘animals’ to see how they can create their first webpage in just five steps. (We’re still working on the ‘Discover’ project type, so if you have any feedback about it, let us know.)
Creators will learn how to use HTML and CSS to build webpages that have:
They will also learn about how to make their webpages accessible to all through use of:
We’ve designed the path so young people can complete it in six one-hour sessions, with one hour for each project. Since the project instructions encourage creators to upgrade their projects, they may wish to go further and spend a little more time getting their projects exactly as they imagine them.
Young people only need a standard web browser to follow the project instructions and use an online code editor to create their webpages.
There are 28 other step-by-step projects for creators to choose from on our website. They can browse through these to see what cool things they’d like to make and what new skills they want to learn.
If your kid is proud of the webpage they create with the final ‘Invent’ project in the path, they can share it with a worldwide community of young creators in our free Coolest Projects tech showcase. Project registration will open again in spring 2023. You can sign up to hear news about the showcase on the Coolest Projects homepage.
The post Get kids creating webpages with HTML and CSS appeared first on Raspberry Pi.
In the penultimate seminar in our series on cross-disciplinary computing, we were delighted to host Conrad Wolfram (European co-founder/CEO of Wolfram Research).
Conrad has been an influential figure in the areas of AI, data science, and computation for over 30 years. The company he co-founded, Wolfram Research, develops computational technologies including the Wolfram programming language, which is used by the Mathematica and WolframAlpha programs. In the seminar, Conrad spoke about his work on developing a mathematics curriculum “for the AI age”.
In his talk, Conrad began by talking about the ubiquity of computation. He explained how computation (i.e. an operation that follows conditions to give a defined output) has transformed our everyday lives and led to the development of entire new sub-disciplines, such as computational medicine, computational marketing, and even computational agriculture. He then used the WolframAlpha tool to give several practical examples of applying high-level computation to problem-solving in different areas.
Conrad then turned his attention to the main question of his talk: if computation has also changed real-world mathematics, how should school-based mathematics teaching respond? He suggested that, as computation has impacted all aspects of our daily lives, school subjects should be reformed to better prepare students for the careers of the future.
His biggest criticism was the use of hand calculation methods in mathematics teaching. He proposed that a mathematics curriculum that “assumes computers exist” and uses computers (rather than humans) to compute answers would better support students to develop a deep understanding of mathematical concepts and principles. In other words, if students spent less time doing hand-calculation methods, they could devote more time to more complex problems.
One interesting aspect of Conrad’s talk was how he modelled the process of solving problems using computation. In all of the example problems, he outlined that computational problem-solving follows the same four-step process:
Depending on the problem, the process can be repeated multiple times until the desired solution is reached. Rather than being proposed as a static list of outcomes, the process was presented by Conrad as an iterative cycle than resembles an “ascending helix”:
In the later stages of his talk, Conrad talked about the development of a new computational curriculum to better define what a modern mathematics curriculum might look like. The platform that hosts the curriculum, named Computer-Based Math (or CBM), outlines the need to integrate computational thinking into mathematics in schools. For instance, one of the modules, How Fast Could I Cycle Stage 7 Of The An Post Rás?, asks students to develop a computational solution to a real-world problem. Following the four-step problem-solving process, students apply mathematical models, computational tools, and real-world data to generate a valid solution:
Some future challenges he remarked on included how a computer-based mathematics curriculum could be integrated with existing curricula or qualifications, at what ages computational mathematics should be taught, and what assessment, training, and hardware would be needed to support teachers to deliver such a curriculum.
Conrad concluded the talk by arguing that the current need for computational literacy is similar to the need for mass literacy and pondering whether the UK could lead the push towards a new computational curriculum suitable for learners who grow up with AI technologies. This point provided food for thought during our discussion section, especially for teachers interested in embedding computation into their lessons, and for researchers thinking about the impact of AI in different fields. We’re grateful to Conrad for speaking about his work and mission — long may it continue!
You can catch up on Conrad’s talk with his slides and the talk’s recording:
Conrad’s book, The Math(s) Fix: An Education Blueprint for the AI Age, gives more details on how he thinks data science, AI, and computation could be embedded into the modern maths curriculum.
You can also explore Wolfram Research’s Computer-Based Maths curriculum, which offers learning materials to help teachers embed computation in their maths lessons.
Finally, try out Wolfram’s tools to solve everyday problems using computation. For example, you might ask WolframAlpha data-rich questions, which the tool converts from text input into a computable problem using natural language processing. (Two of my favourite example questions are: “How old was Leonardo when the Mona Lisa was painted?” and “What was the weather like when I was born?”)
In the final seminar of our series on cross-curricular computing, we welcome Dr Tracy Gardner and Rebecca Franks (Raspberry Pi Foundation) to present their ongoing work on computing education in non-formal settings. Sign up now to join us for this session on Tues 8 November:
We will shortly be announcing the theme of a brand-new series of research seminars starting in January 2023. The seminars will take place online on the first Tuesday of the month at 17:00–18:30 UK time.
The post Building a maths curriculum for a world shaped by computing appeared first on Raspberry Pi.
Introducing children to computing concepts from a young age can help develop their interest and attachment to the subject. While parents might wonder what the best tools and resources are for this, primary and K1–5 educators also need to know what approaches work with their learners.
‘Teaching computing to 5- to 11-year-olds’ is one of the new course pathways we’ve designed to help educators spark young people’s interest in the subject. Our online courses are made by a team of writers, videographers, illustrators, animators, copy editors, presenters, and subject matter experts. They work together over months of production to create high-quality educational video content for participants all over the world.
This course pathway offers advice and practical activities to:
The nine courses included give you a comprehensive understanding of teaching computing to younger learners (5- to 11-year-olds). All the courses have been written by a team of subject matter experts, education professionals, and teachers. Some of the courses cover a specific topic, such as programming or physical computing, while others help educators reflect on their teaching practice.
All of the courses include a range of ideas to use in your own programming sessions. The activities will help you to introduce concepts like computer networks and the internet to young learners in a relatable way. There are also activities to help learners progress within a topic, such as moving from a block-based programming language like Scratch to a text-based one like Python.
The courses are an opportunity to:
These courses will give you everything you need to teach computing to young learners. No computing experience is required.
There is also no specific order in which you need to complete the courses. We want educators to complete the courses in an order that makes sense to them.
If you are new to teaching computing, ‘Get started teaching computing in primary schools’ is the place to start. The four-week course will encourage you to think about why it’s important for your learners to build their understanding around computing. You’ll discover how to support learners to become digital makers who can use technology to solve problems. Everyone who registers on the course will have access to an action plan to help implement what they have learnt into their teaching practice.
These are free courses for anyone, anywhere, who is interested in teaching young people about computing.
All of the courses take between two and four weeks to complete, based on participants spending two hours a week on a course. You will have free access to each course for the length of time it takes to complete it. For example, if it’s a two week course, like ‘Creating an inclusive classroom: approaches to supporting learners with SEND in computing’, you will have two weeks of free access to the course.
Discover what you could learn with ‘Teaching computing to 5- to 11-year-olds’ today.
The post Learn how to teach computing to 5- to 11-year-olds appeared first on Raspberry Pi.
Today we share the second report in our series of findings from the Gender Balance in Computing research programme, which we’ve been running as part of the National Centre for Computing Education and with various partners. In this £2.4 million research programme, funded by the Department for Education in England, we aim to identify ways to encourage more female learners to engage with Computing and choose to study it further.
Previously, we shared the evaluation report about our pilot study of using a storytelling approach with very young computing learners. This new report, again coming from the Behavioural Insights Team (BIT) which acts as the programme’s independent evaluator, describes our study of another teaching approach.
Existing research suggests that computing is not always taught in a way that is engaging for girls in particular [1], and that we can improve this. With the intervention at hand, we wanted to explore the effects of using a pair programming teaching approach with primary school learners aged 8 to 11. We have critically and carefully examined the findings, which show mixed outcomes regarding the effectiveness of the approach, and we believe that the research provides insights that increase our shared understanding of how to teach computing effectively to young learners.
Many people think that writing computer programs is a task carried out by people working individually. A 2017 study of 8- and 9-year-olds [2] confirms this: when asked to draw a picture of a computer scientist doing work, 90% of the children drew a picture of one person working alone. This stereotype is present in teaching and learning about computing and computer science; many computer programming lessons take place in a way that promotes solitary working, with individual students sitting in front of separate computers, working on their own code and debugging their own errors.
Professional software development rarely happens like this. For example, at the Raspberry Pi Foundation, our software engineers work collaboratively on design and often pair up to solve problems. Computing education research also has identified the importance of looking at computer programming through a collaborative lens. This viewpoint allows us to see computing as a subject with scope for collaborative group work in which students create useful applications together and are part of a community where programming has a shared social context [3].
One teaching approach in computing that promotes collaborative learning is pair programming (a practice also used in industry). This is a structured way of working on programming tasks where learners are paired up and take turns acting as the driver or the navigator. The driver controls the keyboard and mouse and types the code. The navigator reads the instructions, supports the driver by watching out for errors in the code, and thinks strategically about next steps and solutions to problems. Learners swap roles every 5 to 10 minutes, to ensure that both partners can contribute equally and actively to the collaborative learning.
As one part of the Gender Balance in Computing programme, we designed a project to explore the effect of pair programming on girls’ attitudes towards computing. This project builds on research from the USA which suggests that solving problems collaboratively increases girls’ persistence when they encounter difficulties in programming tasks [4].
In the Pair Programming project, we worked with teachers of Year 4 (ages 8–9) and Year 6 (ages 10–11) in schools in England. From January to March 2020, we ran a pilot study with 10 schools and used the resulting teacher feedback to finalise the training and teaching materials for a full randomised controlled trial. Due to the coronavirus pandemic, we trained teachers in the pair programming approach using an online course instead of face-to-face training.
The randomised controlled trial ran from September to December 2021 with 97 schools. Schools were randomly allocated to either the intervention group and used the pair programming training and the scheme of work we designed, or to the control group and taught Computing in their usual way. Due to the coronavirus pandemic, our training of teachers in the pair programming approach had to take place via an online course instead of face to face.
Teachers in the intervention group delivered 12 weeks of Computing lessons, in which learners used Scratch programming to draw shapes and create animations. The lessons covered computing concepts from Key Stage 2 (ages 7–11), such as using sequences, selection, and repetition in programs, as well as digital literacy skills such as using technology respectfully.
The pair programming intervention was evaluated independently by an organisation called Behavioural Insights Team (BIT). BIT’s evaluation was primarily based on quantitative data collected from learners at the start and the end of the intervention. To collect the data, they used a validated instrument called the Student Computer Science Attitude Survey (SCSAS), which asks learners about their attitudes towards Computing, along with a few additional survey questions specific to this evaluation. The evaluators compared the data gathered from the intervention group (who took part in pair programming lessons) and the control group (who took part in Computing lessons taught with a ‘business as usual’ model).
The evaluators’ data analysis found no statistically significant evidence that the pair programming approach positively affected girls’ attitudes towards computing or their intention to study computing in the future. The lack of statistically significant results, called a null result in research projects, can appear disappointing at first. But our work involves careful reflection and critical thinking about all outcomes of our research, and the result of this project is no exception. These are factors that may have contributed towards the result:
The evaluators also gathered qualitative data by running teacher and learner interviews and conducting lesson observations, and we were pleased that this data provided some rich insights into the benefits of using a pair programming approach in the primary classroom, and gave some promising indications of possible benefits for female learners in particular.
“I don’t know why I’ve never thought to do computing like that, actually, because it’s a really good vehicle for the fact that there are two roles, clearly defined. There’s all your conversation, and knowledge comes through that, and then they’re both equally having a turn.” — Primary school teacher (report, p. 38)
“I like working with both [both as a partner and by yourself] because when you do pair programming, you’re collaborating with your partner, making links, and you have to tell them what to do. But if you have a really good idea and then they put the wrong thing in the wrong place, it’s quite annoying.” — Female learner (report, p. 40)
“I do think that having that equal time to have a go at both, thinking of the girls I’ve got, will have helped my girls, because they lack a bit of confidence. They were learning very quickly that, ‘Actually, yes, we are sure. We can do this.’” — Primary teacher (report, p. 44)
“It might be easier to do pair programming [compared to ‘normal’ lessons] because if you’re stuck, your partner can be helpful.” — Female learner (report, p. 43)
We will continue to publish evaluation reports and our reflections on the other projects in the Gender Balance in Computing programme. If you would like to stay up-to-date with the programme, you can sign up to the newsletter.
The insights gained from this trial will feed forwards into our future work. Through the process of working with schools on this project, we have increased our understanding of the process of research in educational settings in many ways. We are very grateful for the input from teachers who took part in the first stage of the trial, with whom we developed an effective co-production model for developing resources, a model we will use in future research projects. Teachers who took part in the second stage of the project told us that the resources we provided were of generally good quality, which demonstrates the success of this co-production approach to developing resources.
In our new Raspberry Pi Computing Education Research Centre, created with the University of Cambridge Department of Computer Science and Technology, we will collaborate closely with teachers and schools when implementing and evaluating research projects. You are invited to the free in-person launch event of the Centre on 20 July in Cambridge, UK, where we hope to meet many teachers, researchers, and other education practitioners to strengthen a collaborative community around computing education research.
The post A pair programming approach for engaging girls in the Computing classroom: Study results appeared first on Raspberry Pi.
With our online courses programme, launched in 2017, we made it our mission to provide computing educators with the best possible free training we can design. Five years on, here are some of the key stats about the courses’ impact:
Designed and created in-house, each and every course is a real cross-team effort that involves a lot of careful planning and a number of different stages. Here we’re taking you behind the scenes to show you how we make our courses, introduce you to the people involved, and explain how we ensure our courses are of high quality.
But first, here’s some quick answers to questions you may have:
They are online training courses to help you learn about computing and computing education. The courses are hosted on the FutureLearn website. They are asynchronous, meaning you can take them whenever and wherever you want.
Yes! All our courses are free when you sign up for time-limited access, which gives you full access to the learning materials for the complete course duration. FutureLearn also has a paid-for ‘unlimited’ option, where you receive a certificate for each course you take.
They are aimed at educators, particularly classroom teachers, but they are also beneficial to anyone who wants to learn more about computing.
To help you structure your learning, our courses are divided into three or four weeks, but it’s up to you how quickly you work through them. You can complete a course in one afternoon, or spread your learning out and study for 30 minutes a day over three or four weeks. This flexibility makes it easy to fit a course into a busy schedule.
Creating our online courses is a team effort involving writers, videographers, illustrators, animators, copy editors, presenters, and subject matter experts working together over months of production. The entire process is guided by our online course producers, Martin O’Hanlon, Ross Exton, and Michael Conterio, who know a thing or two about creating high-quality learning experiences. We spoke to them about what it takes to create an engaging course.
Martin: We are driven by the needs of teachers. “What are teachers telling us they want to learn? Or what are the gaps in the curriculum where our learners need additional support?”
For example, our Introduction to Machine Learning and AI course was introduced as a result of feedback from teachers that while the subject wasn’t necessarily on the curriculum, they felt underprepared to answer questions from students or provide context when teaching other topics.
Michael: Working with the course authors, we’ll generally agree on the big topics we want to cover or questions that we want to answer. We’ll often also have individual elements that we want to fit in somewhere, for example an activity involving making a learning resource more accessible. From there it’s a case of taking the bigger topics and working out how we can split them up into smaller chunks, until we get down to individual learning activities.
Ross: But then we’ll end up shuffling things around until we are happy — not only that we’ve got everything that we wanted to cover, but that the overall structure makes sense. We often talk about the ‘narrative’ of a course.
Martin: At the Raspberry Pi Foundation we have a set of 12 pedagogy principles that we use through our learning resources (including online courses). We take particular care to lead with concepts, model processes, and activities; add variety for our learners; and include opportunities to create projects.
Michael: Because the learner is not present, you have to be incredibly precise with instructions as you can’t help learners directly as they are working through the content. And even if you think something is obvious, it’s easy for learners to accidentally miss an instruction, so it’s generally good to try to keep them together rather than spread out.
Martin: Luckily, it is often possible to tell from comments that learners have shared when something is hard to understand so we can improve future runs of the course.
Ross: It’s essential! It brings the abstract concepts of computing to life. The media in our courses helps our learners to visualise the ideas we’re presenting in ways that are engaging and relatable.
As we’re writing the course, we capture every creative idea that will best support our learners in gaining the knowledge and skills that they need. From ‘how-to’ guides with live coding, to physical computing demonstrations, or animations of robots, we think carefully about each image and video and how we’re not just telling the learner something, but showing them.
We then work with a brilliantly talented team of illustrators, animators, videographers, and presenters to create all of that media.
Ross: Social learning is a really important part of our online courses experience. Over the past year we have made significant investment to make it easier for participants to share programs they’ve written as part of their learning, for example, and for facilitators to provide support.
Martin: It is important people have the opportunity to share their learning with others. This is something often lost when taking an online course and it can feel like you are ‘on your own’.
In the Raspberry Pi Foundation’s online courses learners are given the opportunity to ask questions, share what they have created, and provide their own insight in the comments. Educators from the Foundation facilitate the courses — responding to comments and providing advice is a big part of what they do.
Thank you Martin, Michael, and Ross.
What new online course would you like us to create? Tell us in the comments below.
The post How do we create engaging online courses for computing educators? appeared first on Raspberry Pi.
Since the release of the Raspberry Pi Pico microcontroller in 2021, we have seen people all over the world come up with creative Pico-based inventions.
Now, thanks to our brand-new and free ‘Introduction to Raspberry Pi Pico’ learning path, young coders can easily join in and make their own cool Pico projects! This free learning path has six guided projects to help kids to independently develop their coding skills, and their skills in physical computing and electronics.
In this post, I’ll tell you about Raspberry Pi Pico, what kids can make by following our free ‘Intro to Pico’ path, and what skills they will be learning.
Raspberry Pi Pico is a physical computing device that is low-cost and easy to use. It’s much smaller than any Raspberry Pi computer, and it needs much less power. That’s because it’s not a full computer but instead a microcontroller. That means Pico is a device that you program by writing code on any computer, and then sending that code to Pico via a USB cable.
In the ‘Intro to Raspberry Pi Pico’ path, we’ve designed new digital making projects specifically using Pico. By following the projects in the path, young people learn to make things with different electronic components. They’ll bring to life their own LED fireflies; they’ll make music with a sound machine and dial (a potentiometer); they’ll look after themselves and people around them by making a mood indicator and a heart rate visualiser. To find out more, visit the path, or scroll to the bottom of this post and click on ‘Details about the projects’.
The specially designed structure of our learning paths helps kids become confident and independent coders and digital makers. Through this project path, we want to show young people what is possible with Raspberry Pi Pico and inspire them to continue their digital making journey beyond the six projects. Seeing tech creations from our amazing community is super special to us, and we would love to hear about what your young coders have made with Pico. Kids can share their projects in the path gallery, or you can tag us on social media if you post photos!
While young people make all these Raspberry Pi Pico projects, they will learn the skills and independence to make and code their very own, unique creations with a Pico. We have designed our new project paths to help kids become independent digital makers. As they progress through a path, kids gain new skills, practise what they have learnt, and finally write and follow their own project brief.
Our learning paths help kids develop many of the skills that are important to all coders and digital makers, no matter how much experience they have:
The learning paths also encourage kids to make projects about the things that matter to them.
We have written the projects in this path with young people around the age of 9 to 13 in mind.
Programs for Raspberry Pi Pico are written in a text-based language called MicroPython. That means a young person who wants to start the ‘Intro to Pico’ path needs to be familiar with typing on a keyboard.
If your kid has never coded in a text-based language before, they could complete our free ‘Introduction to Python‘ project path first, but this is not a prerequisite.
To help with the programming aspects of the projects, the instructions in the path tell young people about:
One of the great things about this project path is that it helps young people explore physical computing and electronics. In the ‘Intro to Pico’ path, they’ll use:
We’ve designed the path to be completed in around six one-hour sessions, with one hour per project. However, the project instructions encourage kids to upgrade their projects and go further if they wish. This means that they might want to spend a little more time getting their projects exactly as they imagine.
Young people need a web browser so they can follow the project instructions. The first two projects in the path provide detailed instructions for how to install the free software needed for the projects.
The first step of each project lists what components are needed to create the project. You can purchase a kit from Pimoroni that includes all of the components used in the path:
If your young coders enjoy MicroPython, they’ll also love our Python learning paths: ‘Introduction to Python‘ and ‘More Python‘. Both are structured in the same way as our Pico path, and will help young people learn Python while creating their own visual designs.
The post Get kids coding and learning electronics with Raspberry Pi Pico appeared first on Raspberry Pi.
We are excited to announce our second new Python learning path, ‘More Python’, which shows young coders how to add real data to their programs while creating projects from a chart of Olympic medals to an interactive world map. The six guided Python projects in this free learning path are designed to enable young people to independently create their own Python projects about the topics that matter to them.
In this post, we’ll show you how kids use the projects in the ‘More Python’ path, what they can make by following the path, and how the path structure helps them become confident and independent digital makers.
Our ‘Introduction to Python’ learning path is the perfect place to start learning how to use Python, a text-based programming language. When we launched the Intro path in February, we explained why Python is such a popular, useful, and accessible programming language for young people.
Because Python has so much to offer, we have created a second Python path for young people who have learned the basics in the first path. In this new set of six projects, learners will discover new concepts and see how to add different types of real data to their programs.
We have written the projects in this path with young people around the age of 10 to 13 in mind. To code in a text-based language, a young person needs to be familiar with using a keyboard, due to the typing involved. Learners should have already completed the ‘Introduction to Python’ project path, as they will build on the learning from that path.
Young people need access to a web browser to complete our project paths. Each project contains step-by-step instructions for learners to follow, and tick boxes to mark when they complete each step. On top of that, the projects have steps for learners to:
Young people also have the option to sign up for an account with us so they can save their progress at any time and collect badges.
While learners follow the project instructions in this project path, they write their code into Trinket, a free web-based coding platform accessible in a browser. Each project contains a link to a starter Trinket, which includes everything to get started writing Python code — no need to install any additional software.
If they prefer, however, young people also have the option of instead writing their code in a desktop-based programming environment, such as Thonny, as they work through the projects.
To use data in their Python programs, the project instructions show learners how to:
The projects support learners as they explore new concepts of digital visual media and:
In each project, learners reflect and answer questions about their work, which is important for connecting the project’s content to their pre-existing knowledge.
As they work through the projects, learners see different ways to present data and then decide how they want to present their data in the final project in the path. You’ll find out what the projects are on the path page, or at the bottom of this blog post.
The project path helps learners become independent coders and digital makers, as each project contains slightly less support than the one before. You can read about how our project paths are designed to increase young people’s independence, and explore our other free learning paths for young coders
We’ve designed the path to be completed in around six one-hour sessions, with one hour per project, at home, in school, or at a coding club. The project instructions encourage learners to add code to upgrade their projects and go further if they wish. This means that young people might want to spend a little more time getting their projects exactly as they imagine them.
Unity is a free development environment for creating 3D virtual environments, including games, visual novels, and animations, all with the text-based programming language C#. Our ‘Introduction to Unity’ project path for keen coders shows how to make 3D worlds and games with collectibles, timers, and non-player characters.
At the end of the ‘More Python’ path, learners are encouraged to register a project they’ve made using their new coding skills for Coolest Projects Global, our free and world-leading online technology showcase for young tech creators. The project they register will become part of the online gallery, where members of the Coolest Projects community can celebrate each other’s creations.
We welcome projects from all young people, whether they are beginners or experienced coders and digital makers. Coolest Projects Global is a unique opportunity for young people to share their ingenuity with the world and with other young people who love coding and creating with digital technology.
The post Python coding for kids: Moving beyond the basics appeared first on Raspberry Pi.
Raspberry Pi Pico powers this real-time audio spectrogram visualiser using a digital microphone to pick up the sound and an LCD display to show us what those sounds “look” like.
First off, let’s make sure we know what all of those words mean, because “audio spectrogram visualiser” is a bit of a mouthful:
This pocket-sized device can be carried around with you and lets you see a visual representation of your surrounding audio environment in real time. So, if you wander into a peaceful bird reserve or something, the LCD display will show you something very different to what you’d see if you were in, say, Wembley Stadium during an FA Cup final.
Above, you can see Sandeep’s creation in action in the vicinity of a crying baby.
That is a satisfyingly affordable hardware list.
In the video below, you can see there is a direct correlation between the original audio signal’s amplitude (on the left) and the audio spectrogram’s representation of the signal on the right.
The Microphone Library for Pico captures data from Sandeep’s digital microphone. Arm’s CMSIS-DSP library processes the audio in real-time, then transforms it into spectrograms. These are then displayed one row at a time on the LCD screen, using the ST7789 Library for Pico.
Maker Sandeep Mistry created the original project guide on behalf of the Arm Software Developers team. Check out his other tutorial on how to create a USB Microphone with the Raspberry Pi Pico.
The post See what sounds look like with Raspberry Pi Pico appeared first on 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.
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.
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.
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.
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.
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.”
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 Who remembers E.T. for the Atari 2600? appeared first on 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.
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.
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.
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!
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.
We love Wireframe magazine’s regular feature ‘The principles of game design’. They’re written by video game pioneer Howard Scott Warshaw, who authored several of Atari’s most famous and infamous titles. In the latest issue of Wireframe, he provides a snapshot of the hell-raising that went on behind the scenes at Atari…
Video game creation is unusual in that developers need to be focused intently on achieving design goals while simultaneously battling tunnel vision and re-evaluating those goals. It’s a demanding and frustrating predicament. Therefore, a solid video game creator needs two things: a way to let ideas simmer (since rumination is how games grow from mediocre to fabulous) and a way to blow off steam (since frustration abounds while trying to achieve fabulous). At Atari, there was one place where things both simmered and got steamy… the hot tub. The only thing we couldn’t do was keep a lid on the antics cooked up inside.
The hot tub was situated in the two-storey engineering building. This was ironic, because the hot tub generated way more than two stories in that building. The VCS/2600 and Home Computer development groups were upstairs. The first floor held coin-op development, a kitchen/cafeteria, and an extremely well-appointed gym. The gym featured two appendages: a locker area and the hot tub room. Many shenanigans were hatched and/or executed in the hot tub. One from the more epic end of the spectrum comes to mind: the executive birthday surprise.
It was during the birthday celebration of a VP who shall remain nameless, but it might have been the one who used to keep a canister of nitrous oxide and another of pure oxygen in his office. The nitrous oxide was for getting high and laughing some time away, while the oxygen was used for rapid sobering up in the event a spontaneous meeting was called (which happened regularly at Atari). As the party raged on, a small crew of revellers migrated to the small but accommodating hot tub room. Various intoxicants (well beyond the scope of nitrous) were being consumed in celebration of the special event (although by this standard, nearly every day was a special event at Atari).
As the party rolled on, inhibitions were shed along with numerous articles of clothing. At one point, the birthday boy was adjudged to be in dire need of a proper tubbing as he hadn’t lost sufficient layers to keep pace with the party at large. The birthday boy disagreed, and the ensuing negotiation took the form of a lively chase around the area. The VP ran out of the hot tub room and headed for the workout area with a wet posse in hot pursuit, all in varying stages of undress.
It’s important to note here that although refreshments and revelry were widely available at Atari, one item in short supply was conference rooms. Consequently, meetings could pop up in odd locales. Any place an aggregation could be achieved was a potential meeting spot. The sensitivity of the subject matter would determine the level of privacy required on a case-by-case basis. Since people weren’t always working out, the gym had enough places to sit that it could serve as a decent host for gatherings. And as for sensitivity, the hot tub room was well sound-proofed, so intruding ears weren’t a concern.
As the crew of rowdy revellers followed the VP into the workout area, they were confronted by just such a collection of executives who happened to be meeting at the time. I don’t think the birthday party was on the agenda. However, they may have been pleased that the absentee VP had ultimately decided to join their number. It was embarrassing for some, entertaining for others, and nearly career-ending for a couple. The moral of this story being that Atari executives should never go anywhere without their oxygen tanks in tow.
But morals aside, there was work to be done at Atari. In a place where work can lead to antics and antics can lead to work breakthroughs, it’s difficult at times to suss out the precise boundary between work and antics. It takes passion and commitment to pursue side quests productively and yet remain on task when necessary.
The main reason this was a challenge comes down to the fact there are so many distractions constantly going on. Creative people tend to be creative frequently and spontaneously. Also, their creativity is much more motivated by fascination and interest than it is by task lists or project plans. Fun can break out at any moment, and answering the call isn’t always the right choice, no matter how compelling the siren.
Rob Fulop, creator of Missile Command and Demon Attack for the Atari 2600 (among many other hits) isn’t only a great game maker, he’s also a keen observer of human nature. We used to chat about just where the edge is between work and play at Atari. Those who misjudge it can easily fall off the cliff.
Likewise, we explored the concept of what makes a good game designer. Rob said it’s just the right combination of silly and anal. He believed that the people who did well at Atari (and as game makers in general) were the people who could be silly enough to recognise fun, and anal enough to get all the minutia and details aligned correctly in order to deliver the fun. Of course, Rob (being the poet he is) created a wonderful phrasing to describe those with the right stuff. He put it like this: the people who did well at Atari were the people who could goof around as much as possible but still go to heaven.
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 Behind the scenes at Atari appeared first on 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.
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.
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.
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…
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.
In game design, freedom can lead to paralysis. But in the latest issue of Wireframe magazine, Stuart Maine explains how game pillars and the iron triangle will help you focus on what’s important.
This article will cover two game development tools that are designed to help decide what’s important in the game you’re making. The iron triangle revolves around the practical realities of making a game, while game pillars cover the creative side, but both relate to the importance of focus. Let’s begin with pillars.
Every game media has its strengths, such as wargaming’s communities, the shared experiences of board games, or the collaboration of RPGs. One of the advantages of video games is their sheer flexibility – we can race across alien worlds, explore Egyptian tombs, or keep fit while going on magical quests. But that infinite flexibility can be a real problem for game creators, because if the game you’re making can include literally anything, then how do you know what to focus on?
Let’s assume you have an idea for a game based on a particular world or character, or a certain type of gameplay. Alternatively, you might have used player types (see Wireframe issue 39) to decide on a particular audience and the features they like, or if you’re working with someone else’s IP, then that brand’s owners might have a type of gameplay in mind. Game pillars help move beyond those starting points and guide you through development.
A game’s pillars are a list of around three ‘core statements’ created early in that game’s development. You could come up with your pillars before you’ve started development to help narrow down the possible game you might make, or you might do this after prototyping has given you an idea you want to pursue. You can even retroactively create pillars to help rescue a game that’s been in development for a while and has lost its way.
It’s easy to write ‘our game will feature 2D puzzles and platforming’, and technically that is a pillar because you can refer back to it later. But it doesn’t really say anything about what that platforming is for. By that, I mean why are you making a game about platforming? To dig deeper into the ‘why’ behind your pillar, you could rewrite that sentence to one of these:
Those are my example guesses at a pillar each for the platform games Flashback, Spelunky, and Celeste. All are 2D platformers, but they’re ‘about’ very different things.
Note that none of the above examples specifically talk about the gameplay being platforming, because pillars should focus on the feelings and emotions you want your game to evoke, rather than how you’re going to do it. That’s because pillars aren’t a feature list to check off, more a tool to help remember the things that are important when you’re submerged in the day-to-day realities of game development. Pillars are the why of your game, and the actual development process is coming up with the what to match those initial goals.
Print your chosen pillars as large as you can and put them up somewhere you’ll see them every day. That way they’ll become ingrained in your thoughts and you’ll easily be able to refer to them when someone suggests a new feature or change to the game. Will that change help bring your game closer to your pillars (great), not really affect them (neutral), or work against them (bad)?
I’ve seen studios use pillars on struggling games to discard any areas which don’t match them. You particularly see this if a game is taking too long to release (because most professional studios have to get a game out to some sort of deadline – more on this below), with people looking back to their pillars to help work out what to cut. If feature A is cool, but feature B aligns with the pillars, it’ll take a strong argument to keep A.
There are a couple of approaches for coming up with a game’s pillars, each with advantages, but also potential problems to look out for. Both of these approaches assume you already know to some degree what the game will be. Your pillars will help guide the eventual game’s details, but they’re a tool for staying on track as you forge ahead, not for coming up with ideas in the first place. If you haven’t agreed on a concept for your game yet, then run game jams, conduct audience and market research, or paper prototype ideas first.
Second, both approaches assume any business, audience, IP, or technology factors are already agreed and set in stone. For example, you might already know that this will be a multiplayer game, that it must be released within this time frame, or that it must be built on the technology created for your previous game. We’ll talk more about this with the iron triangle, but basically, any real-world issues that are beyond your control must be acknowledged or you risk coming up with pillars that set you up for difficulties later.
The two approaches are to have the entire team brainstorm potential pillars, or have vision holders dictate them:
ONE: If the entire team is involved, then you run brainstorming sessions where everyone’s potential pillar ideas are stuck up on a wall. Then the group chooses the best pillars or combines a couple of ideas into pillars (remember the point about keeping them short – mashing many ideas into a long pillar is cheating).
The advantage of this approach is that everyone understands and buys into the chosen pillars because they had a say in creating them. The downside is that this process can take time, with potentially conflicting ideas needing to be whittled down until an agreement is reached.
TWO: The other approach is for ‘creative vision holders’ to come up with the game’s pillars and then present them to the rest of the team. Obviously, this is much less collaborative and more about saying, ‘I have a vision for this game which I think could be incredible, will you help me make it?’ The advantage of this is that everyone can rally behind a singular vision that someone is passionate about bringing to the world. As a result, the game’s pillars are likely to be extremely focused and all pointing in the same direction. The downside is that it requires everyone else to get on board with the game’s pillars even though they didn’t help come up with them.
Either way, once the pillars have been created, everyone on the team has to work with them in mind – there’s an implied contract that these rules must be enforced to ensure the game keeps moving in the right direction. Even though it can be unpopular to say no to someone’s idea, that’s what pillars are there to help with (and of course, pillars don’t say ‘that idea is bad’, simply that it doesn’t fit this particular game. Write the idea down and maybe build your next game around it).
Here are some actual pillars from games I’ve worked on:
I realise that game pillars are quite an abstract topic, but in my experience across many games and studios, they have proven their worth. At the start of a project, they help avoid the ‘blank page’ problem of being able to make anything you can imagine, and later they help you say ‘this, but not that’ and avoid wandering in the development wilderness. So however you choose to structure or word your game pillars, I wholeheartedly recommend spending a little time thinking about the why before you launch into the what.
Speaking of which, let’s take a look at the iron triangle and how it will impact your game, because no matter what you do in the games industry, the triangle will impact you. As a result, it’s important to have an idea of how it works and what it means to your projects. A quick disclaimer: I’m going to simplify a complex area for space reasons, so if it interests you, check out online resources on this and other project management topics.
Have you ever played a game and clearly seen that it was unfinished? Missing features, obvious bugs, and a lack of polish show that you’re playing a game that needed more development time. The iron triangle is the reason games are released in an unfinished state, but it isn’t some malevolent force – it’s simply where reality butts up against creativity in game development.
Coined by Dr. Martin Barnes, the triangle applies to premium games as much as free ones, and to indie games as equally as blockbusters. It relates to…
Now we know the three points of the iron triangle – where things get interesting is that those points are all interrelated, and the rule is you can only control two of the three points. You can select which two points you want to control, but you have no say on what happens to the third. That’s why it’s called an iron triangle – the outcome of the third point is decided by what you do with the two you’ve chosen to control.
These are the outcomes you can expect based on the two points of the triangle you choose to control:
You might be wondering why any of this matters – after all, you could be making a game in your spare time or working at a studio where other people make these decisions. But if you understand which of the points of the triangle your project is trying to control, then you can work more effectively, making choices that work towards those needs rather than against them.
As a side note, if you’re working at a studio and whoever’s in charge insists they can control all three points of the iron triangle, consider that a Big Red Warning. That sort of denial of the fundamentals of project management means overtime – and a game that’s likely to go off the rails.
The iron triangle isn’t about hateful business realities quashing your creative dreams, it’s about choosing and understanding your priorities so that you control your game, not the other way around.
To recap: choosing your game’s pillars helps you focus on what’s important, and choosing which two points of the iron triangle you want to control helps you focus on the reality of making a game. Both of these are important, because not deciding on a game’s pillars can lead to the end result being a mess of conflicting ideas pulling in multiple directions, and ignoring the iron triangle leads to games spiralling into overtime, delays, and impossible demands. Yes, making games should be fun, but a little focus early in a project’s life can pay off big time later on.
You can read more features like this one in Wireframe issue 52, 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 52 for free in PDF format.
The post How pillars and triangles can focus your game design appeared first on 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.
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.
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.
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.
You can read more features like this one in Wireframe issue 52, 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 52 for free in PDF format.
The post Recreate Gradius’ rock-spewing volcanoes | Wireframe #52 appeared first on Raspberry Pi.
Musician, producer, and Twitch star Katt Strike chats to Wireframe magazine about video games, toxicity online and the appeal of streaming.
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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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.
Keza MacDonald has been a video games journalist and critic for more than 15 years, and is currently video games editor at The Guardian. In the latest issue of Wireframe magazine, she tells us how her love affair with the Japanese gaming industry started.
When I was a kid, Japan was synonymous with video games. Unlike the home-computer-raised British children of the 1980s, I grew up with Nintendo (and, more reluctantly, with Sega), and later with PlayStation. My first console was a SNES, my second an N64, my third a PlayStation 2, and my fourth a Dreamcast bought on the cheap just after it was discontinued, and all of my formative gaming experiences were Japanese.
I’m not just talking about the obvious stuff, though naturally Mario, Zelda, and Pokémon were a huge part of my childhood. I used to sit and peruse issues of Super Play and N64 Magazine in the magazine aisle of the supermarket whilst my dad did the weekly shop, poring over tiny screenshots of mysterious imported Japanese games like 64 Ōzumō and Harvest Moon. For my N64, I didn’t buy GoldenEye (primarily because my mum wouldn’t let me, but still) – I bought Konami’s Mystical Ninja Starring Goemon, a bizarre musical RPG set in a surreal Edo-period-inspired Japan. I bought Treasure’s bizarre action game, Mischief Makers. On Dreamcast, my introduction to Sega consisted of Space Channel 5, Shenmue, and Crazy Taxi.
Later on, as a teenager, I became a bit of a specialist in digging out obscure Japanese games on the PlayStation 2 and GameCube. I played bizarre evolution game Cubivore, innovative music game Mojib-Ribbon, even more innovative musical shooter Rez, and Chulip (a game about arriving in a new town and working your way up to kissing the girl of your dreams, starting with kissing the upside-down gimp hanging around in the sewer). I discovered, and very quickly became obsessed with, Bemani games like Guitar Freaks and Dance Dance Revolution. I loved the diversity and creativity of Japanese games, and the fact that I often encountered something entirely unexpected in them. Having grown up in a different culture, the language of their cultural references and their sense of humour was intriguingly new to me.
I learned katakana as a teen so that I could read basic menus and muddle my way through imported games. Later, at university, I studied Japanese so that I could spend a year abroad; when I landed in Nagoya, a city on the coast between Tokyo and Kyoto where I spent some of the happiest and most fun months of my life, I remember being weirded out by a sense of déjà vu. I kind of had been there before, but only in games like Shenmue. I had a great time exploring arcades, spending most of my money on random bargain-bin N64 games, travelling the country, and being extremely laissez-faire with my actual studying.
This was in 2008, and what I was witnessing was the tail-end of Japan’s cultural domination of video games. My favourite Shibuya arcade has closed now. Some of the others I used to frequent are still there, but increasingly full of UFO grabbers rather than old Street Fighter cabinets or mysterious rhythm-action games. Shooters and open-world games were becoming the dominant genres, and Japan did neither of them well. Ahead of Keiji Inafune’s famous proclamation that Japan’s games industry was dead in 2009, The “Is Japan over?” op-eds had already started, as the publishers and developers that made many of the weirdest games of my childhood started to fold, the industry started to globalise, and online play became the norm.
Since then, indie games have had a resurgence, but Japan has never developed a particularly robust indie scene. Its games industry still revolves around the huge companies that forged it. We’ve still got Nintendo, Capcom, and Square Enix, but others like Konami and Sega are shadows of their former selves, and we’ve lost Sony’s Japan Studio among many others. Japan hasn’t been at the epicentre of the games industry for many years now. But for those who grew up when I did, it will always be its true home.
You can read more features like this one in Wireframe issue 50, 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 50 for free in PDF format.
The post Keza’s love for the Japanese games industry appeared first on Raspberry Pi.
Blast dive-bombing aliens in our salute to Namco’s classic. Mark Vanstone has the code
Hot on the heels of the original Space Invaders, Galaxian emerged as a rival space shooter in 1979. Released by Namco, Galaxian brought new colour and unpredictable motion to the alien enemy, who would swoop down on the defending player. Galaxian was so popular in arcades that Namco released a sequel, Galaga, two years later – that game complicated the attack patterns even more. It’s difficult to say how many ports and clones have been made of Galaxian, as there are several versions of similar games for almost every home platform.
The player’s role in Galaxian is similar to Space Invaders, in that they pilot a ship and need to destroy a fleet of aliens. With Galaxian, however, the aliens have a habit of breaking formation and swooping down towards the player’s ship, and dive-bombing it. The aim is to destroy all the enemy ships and move on to the next wave. The subsequent waves of enemies get more difficult as the player progresses. For this sample, we’re going to look at that swooping mechanic, and make the bare nuts and bolts of a Galaxian game with Pygame Zero.
First, Galaxian has a portrait display, so we can set the play area’s width and height to be 600 and 800 respectively. Next, we can create a scrolling backdrop of stars using a bitmap that we blit to the screen and move downwards every update. We need a second blit of the stars to fill in the space that the first one leaves as it scrolls down, and we could also have another static background image behind them, which will provide a sense of depth.
Next, we set up the player ship as an Actor, and we’ll capture the left and right arrow keys in the update() function to move the ship left and right on the screen. We can also fire off a bullet with the SPACE bar, which will travel up the screen until it hits an alien or goes off the top of the screen. As in the original Galaxian, you can only shoot one bullet at a time, so we only need one Actor for this.
The aliens are arranged in rows and move left and right across the screen together. We’ll stick to just one type of alien for this sample, but draw two rows of them. You could add extra types and any number of rows. When we create the alien Actors, we can also add a status flag, and we need to determine which side of the row they’re on as when they break formation, the two sides fly in opposite directions. In this case, there’ll be four aliens on the left of each row and four on the right. Once they’re set up in a list, we can iterate through the list on each update and move them backwards and forwards. While we’re moving our aliens, we can also check to see if they’ve collided with a bullet or the player ship. If the collision is with a bullet, the alien cycles through a few frames of an explosion using the status flag, and then, when their status reaches five, they’re no longer drawn. If the collision is with the player, then the player dies and the game’s over. We can also check a random number to see if the alien will start a bombing run; if so, we set the status to one, which will start calls to the flyAlien() function. This function checks which side the alien’s on and starts changing the alien’s angle, depending on the side. It also alters the x and y coordinates, depending on the angle. We’ve written this section in longhand for clarity, but this could be collapsed down a bit with the use of some multiplier variables for the x coordinates and the angles.
There we have it: the basics of Galaxian. Can you flesh it out into a full game?
You can read more features like this one in Wireframe issue 50, 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 50 for free in PDF format.
The post Recreate Galaxian’s iconic attack patterns | Wireframe #50 appeared first on Raspberry Pi.
Want to connect your retro console to your modern TV? The latest issue of Wireframe magazine has the only guide you need, courtesy of My Life in Gaming’s Mark Duddleson.
“Get a Raspberry Pi. Done.” It’s probably the most frequently recurring comment we get across all videos on the My Life in Gaming YouTube channel, which often revolve around playing classic games on original hardware. Not everyone has held onto their old consoles through the years, so I get it.
Software emulation, whether through a PC, Raspberry Pi, or any other device, is easy on your wallet and solid enough to give most people the experience they’re looking for.
But for me, the core of my gaming experience still tends to revolve around the joy I feel in using authentic cartridges and discs. But as you may have noticed, 2021 isn’t 2001, and using pre-HDMI consoles isn’t so easy these days. A standard CRT television is the most direct route to getting a solid experience with vintage consoles.
But let’s face it – not everyone is willing to work a CRT into their setup. Plenty of people are content with just plugging the cables that came with their old systems (usually composite) into their HD or 4K TV – and that’s OK! But whether for the blurry looks or the input lag they feel, this simply isn’t good enough for a lot of people.
“There has to be a better way,” you say as you browse Amazon’s assortment of analogue-to- HDMI converters, HDMI adapters like Wii2HDMI, or HDMI cables for specific consoles by a variety of brands. You might think these are just what you’re looking for, but remember: your TV has its own internal video processor. Just like your TV, they’re going to treat 240p like 480i. Not only is it unnecessary to deinterlace 240p, but doing so actively degrades the experience – motion- adaptive deinterlacing takes time, adding input lag.
That Sega Saturn HDMI cable is going to deinterlace your gorgeous 240p sprite-based games so hard that they’ll look like some sort of art restoration disaster in motion. The dark secret of these products is that you’re buying something you already own – a basic video processor designed for video, not video games, and the result will likely not be tangibly better than what your TV could do. The only reason to go this route is if you have no analogue inputs and could not possibly invest more than $30.
So what is the better way? The primary purpose of an external video processor is to send a properly handled signal to your TV that won’t trigger its lag-inducing processes and turn your pixels into sludge – basically any progressive resolution other than 240p. Luckily, there are several devices in various price ranges that are designed to do exactly this.
This is just a tiny snippet of the mammoth feature in Wireframe magazine issue 49. The main feature includes a ‘jargon cheat sheet’ and ‘cable table’ to make sure any level of user can get their retro console working on a modern TV.
If you’re not a Wireframe magazine subscriber, you can download a PDF copy for free. Head to page 50 to get started.
You can read more features like this one in Wireframe issue 49, available directly from Raspberry Pi Press — we deliver worldwide.
The post Play your retro console on a modern TV appeared first on Raspberry Pi.
Traverse a crumbly cavern in our homage to a Spectrum classic. Mark Vanstone has the code
One of the most iconic games on the Sinclair ZX Spectrum featured a little man called Miner Willy, who spent his days walking and jumping from platform to platform collecting the items needed to unlock the door on each screen. Manic Miner’s underground world featured caverns, processing plants, killer telephones, and even a forest featuring little critters that looked suspiciously like Ewoks.
Written by programmer Matthew Smith and released by Bug-Byte in 1983, the game became one of the most successful titles on the Spectrum. Smith was only 16 when he wrote Manic Miner and even constructed his own hardware to speed up the development process, assembling the code on a TRS-80 and then downloading it to the Spectrum with his own hand-built interface. The success of Manic Miner was then closely followed by Jet Set Willy, featuring the same character, and although they were originally written for the Spectrum, the games very soon made it onto just about every home computer of the time.
Both Manic Miner and Jet Set Willy featured unstable platforms which crumbled in Willy’s wake, and it’s these we’re going to try to recreate this month. In this Pygame Zero example, we need three frames of animation for each of the two directions of movement. As we press the arrow keys we can move the Actor left and right, and in this case, we’ll decide which frame to display based on a count variable, which is incremented each time our update() function runs. We can create platforms from a two-dimensional data list representing positions on the screen with 0 meaning a blank space, 1 being a solid platform, and 2 a collapsible platform. To set these up, we run through the list and make Actor objects for each platform segment.
For our draw() function, we can blit a background graphic, then Miner Willy, and then our platform blocks. During our update() function, apart from checking key presses, we also need to do some gravity calculations. This will mean that if Willy isn’t standing on a platform or jumping, he’ll start to fall towards the bottom of the screen. Instead of checking to see if Willy has collided with the whole platform, we only check to see if his feet are in contact with the top. This means he can jump up through the platforms but will then land on the top and stop. We set a variable to indicate that Willy’s standing on the ground so that when the SPACE bar is pressed, we know if he can jump or not. While we’re checking if Willy’s on a platform, we also check to see if it’s a collapsible one, and if so, we start a timer so that the platform moves downwards and eventually disappears. Once it’s gone, Willy will fall through. The reason we have a delayed timer rather than just starting the platform heading straight down is so that Willy can run across many tiles before they collapse, but his way back will quickly disappear. The disappearing platforms are achieved by changing the image of the platform block as it moves downward.
As we’ve seen, there were several other elements to each Manic Miner screen, such as roaming bears that definitely weren’t from Star Wars, and those dastardly killer telephones. We’ll leave you to add those.
You can read more features like this one in Wireframe issue 49, 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 49 for free in PDF format.
The post Remake Manic Miner’s collapsing platforms | Wireframe #49 appeared first on Raspberry Pi.
Updating a 22-year-old game brought Andrew Gillett face to face with some very poor coding practices. Read more about it in this brilliant guest article from the latest issue of Wireframe magazine.
In 1998, at the age of 17, I was learning how to write games in C. My first attempt, the subtly titled DEATH, was not going well. The game was my take on Hardcore, a 1992 Atari ST game by legendary game developer and sheep enthusiast Jeff Minter, which had been released only as an unfinished five-level demo.
The player controlled four gun turrets on the outside of a square arena, into which enemies teleported. While the original game had been enjoyable and promising, my version wasn’t much fun, and I couldn’t work out why. Making a decent game would also have involved making dozens of levels and many enemy types, which was looking like too big a task, especially as I was finding it hard to understand the intricacies of how the enemies in Hardcore moved.
So I abandoned that game and decided to replicate a different one – 1994’s MasterBlaster, a Bomberman-style game on the Commodore Amiga. MasterBlaster didn’t have a single-player mode or bots, so there was no enemy AI to write. And the level was just a grid with randomly generated walls and power-ups – so there was no real level design involved. With those two hurdles removed, development went fairly smoothly, the biggest challenge being working out some of the subtleties of how character movement worked.
The game, which I named Partition Sector, was finished in mid-1999 and spent the next 18 years on my website being downloaded by very few people. In late 2018 I decided to do a quick update to the game and release it on Steam. Then I started having ideas, and ended up working on it, on and off, for two years.
One of the biggest hurdles I came across when writing my first games was how to structure the code. I knew how to write a basic game loop, in which you update the positions of objects within the game, then draw the level and the objects within it, and then loop back to the start, ending the loop when the ‘game over’ criteria are met or the player has chosen to quit. But for a full game you need things like a main menu, submenus, going through a particular number of rounds before returning to the main menu, and so on. In the end, I was able to come up with something that worked, but looking back on my old code 20 years on, I could see many cases of absolutely terrible practice.
“I started having ideas, and ended up working on it, on
and off, for two years”
While most of my time was spent adding new features, a lot of time was spent rewriting and restructuring old code. I’m going to share some examples from the original code so you don’t make the same mistakes!
This is just a snippet of Andrew’s brilliant monster-sized tutorial, which you can read in full in the latest issue of Wireframe magazine. No subscription? No problem! You can read the rest of this post in full for free in PDF format.
The post How not to code: a guide to concise programming appeared first on Raspberry Pi.
Grab onto ropes and swing across chasms in our Python rendition of an Atari 2600 classic. Mark Vanstone has the code
Whether it was because of the design brilliance of the game itself or because Raiders of the Lost Ark had just hit the box office, Pitfall Harry became a popular character on the Atari 2600 in 1982.
His hazardous attempts to collect treasure struck a chord with eighties gamers, and saw Pitfall!, released by Activision, sell over four million copies. A sequel, Pitfall II: The Lost Caverns quickly followed the next year, and the game was ported to several other systems, even making its way to smartphones and tablets in the 21st century.
Designed by David Crane, Pitfall! was released for the Atari 2600 and published by Activision in 1982
The game itself is a quest to find 32 items of treasure within a 20-minute time limit. There are a variety of hazards for Pitfall Harry to navigate around and over, including rolling logs, animals, and holes in the ground. Some of these holes can be jumped over, but some are too wide and have a convenient rope swinging from a tree to aid our explorer in getting to the other side of the screen. Harry must jump towards the rope as it moves towards him and then hang on as it swings him over the pit, releasing his grip at the other end to land safely back on firm ground.
For this code sample, we’ll concentrate on the rope swinging (and catching) mechanic. Using Pygame Zero, we can get our basic display set up quickly. In this case, we can split the background into three layers: the background, including the back of the pathway and the tree trunks, the treetops, and the front of the pathway. With these layers we can have a rope swinging with its pivot point behind the leaves of the trees, and, if Harry gets a jump wrong, it will look like he falls down the hole in the ground. The order in which we draw these to the screen is background, rope, tree-tops, Harry, and finally the front of the pathway.
Now, let’s get our rope swinging. We can create an Actor and anchor it to the centre and top of its bounding box. If we rotate it by changing the angle property of the Actor, then it will rotate at the top of the Actor rather than the mid-point. We can make the rope swing between -45 degrees and 45 degrees by increments of 1, but if we do this, we get a rather robotic sort of movement. To fix this, we add an ‘easing’ value which we can calculate using a square root to make the rope slow down as it reaches the extremes of the swing.
Our homage to the classic Pitfall! Atari game. Can you add some rolling logs and other hazards?
Our Harry character will need to be able to run backwards and forwards, so we’ll need a few frames of animation. There are several ways of coding this, but for now, we can take the x coordinate and work out which frame to display as the x value changes. If we have four frames of running animation, then we would use the %4 operator and value on the x coordinate to give us animation frames of 0, 1, 2, and 3. We use these frames for running to the right, and if he’s running to the left, we just mirror the images. We can check to see if Harry is on the ground or over the pit, and if he needs to be falling downward, we add to his y coordinate. If he’s jumping (by pressing the SPACE bar), we reduce his y coordinate.
We now need to check if Harry has reached the rope, so after a collision, we check to see if he’s connected with it, and if he has, we mark him as attached and then move him with the end of the rope until the player presses the SPACE bar and he can jump off at the other side. If he’s swung far enough, he should land safely and not fall down the pit. If he falls, then the player can have another go by pressing the SPACE bar to reset Harry back to the start.
That should get Pitfall Harry over one particular obstacle, but the original game had several other challenges to tackle – we’ll leave you to add those for yourselves.
Here’s Mark’s code for a Pitfall!-style platformer. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.
The post Swing into action with an homage to Pitfall! | Wireframe #48 appeared first on Raspberry Pi.
Speed around an arena, avoiding walls and deadly trails in this Light Cycle minigame. Mark Vanstone has the code.
At the beginning of the 1980s, Disney made plans for an entirely new kind of animated movie that used cutting-edge computer graphics. The resulting film was 1982’s TRON, and it inevitably sparked one of the earliest tie-in arcade machines.
Battle against AI enemies in the original arcade classic.
The game featured several minigames, including one based on the Light Cycle section of the movie, where players speed around an arena on high-tech motorbikes, which leave a deadly trail of light in their wake. If competitors hit any walls or cross the path of any trails, then it’s game over.
Players progress through the twelve levels which were all named after programming languages. In the Light Cycle game, the players compete against AI players who drive yellow Light Cycles around the arena. As the levels progress, more AI Players are added.
The TRON game, distributed by Bally Midway, was well-received in arcades, and even won Electronic Games Magazine’s (presumably) coveted Coin-operated Game of the Year gong.
Although the arcade game wasn’t ported to home computers at the time, several similar games – and outright clones – emerged, such as the unsubtly named Light Cycle for the BBC Micro, Oric, and ZX Spectrum.
The Light Cycle minigame is essentially a variation on Snake, with the player leaving a trail behind them as they move around the screen. There are various ways to code this with Pygame Zero.
Our homage to the TRON Light Cycle classic arcade game.
In this sample, we’ll focus on the movement of the player Light Cycle and creating the trails that are left behind as it moves around the screen. We could use line drawing functions for the trail behind the bike, or go for a system like Snake, where blocks are added to the trail as the player moves.
In this example, though, we’re going to use a two-dimensional list as a matrix of positions on the screen. This means that wherever the player moves on the screen, we can set the position as visited or check to see if it’s been visited before and, if so, trigger an end-game event.
For the main draw() function, we first blit our background image which is the cross-hatched arena, then we iterate through our two-dimensional list of screen positions (each 10 pixels square) displaying a square anywhere the Cycle has been. The Cycle is then drawn and we can add a display of the score.
The update() function contains code to move the Cycle and check for collisions. We use a list of directions in degrees to control the angle the player is pointing, and another list of x and y increments for each direction. Each update we add x and y coordinates to the Cycle actor to move it in the direction that it’s pointing multiplied by our speed variable.
We have an on_key_down() function defined to handle changing the direction of the Cycle actor with the arrow keys. We need to wait a while before checking for collisions on the current position, as the Cycle won’t have moved away for several updates, so each screen position in the matrix is actually a counter of how many updates it’s been there for.
We can then test to see if 15 updates have happened before testing the square for collisions, which gives our Cycle enough time to clear the area. If we do detect a collision, then we can start the game-end sequence.
We set the gamestate variable to 1, which then means the update() function uses that variable as a counter to run through the frames of animation for the Cycle’s explosion. Once it reaches the end of the sequence, the game stops.
We have a key press defined (the SPACE bar) in the on_key_down() function to call our init() function, which will not only set up variables when the game starts but sets things back to their starting state.
Here’s Mark’s code for a TRON-style Light Cycle minigame. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.
So that’s the fundamentals of the player Light Cycle movement and collision checking. To make it more like the original arcade game, why not try experimenting with the code and adding a few computer-controlled rivals?
You can read more features like this one in Wireframe issue 47, 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 47 for free in PDF format.
The post Code a Light Cycle arcade minigame | Wireframe #47 appeared first on Raspberry Pi.
