The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

ArcadeRS 1.0: The project

2015-07-04: Original article. 2015-07-25: Changed library to rust-sdl2 0.6, no change to rust code. 2015-10-17: Changed library to rust-sdl2 0.9; increased the date of publication. 2016-01-21: Changed library to rust-sdl2 0.13, minimal change to rust code.

This is the introduction of a series whose objective is to explore the Rust programming language and ecosystem through the development of a simple, old-school shooter. It is composed of 16 parts, excluding this introduction:

  1. A simple window, where we install SDL2
  2. Event handling, where we discuss lifetimes
  3. More event handling, where we discuss macros
  4. Views, where we learn about boxes, pattern matching, trait objects, and dynamic dispatch
  5. Switching views, where we use boxes, pattern matching, trait objects, and dynamic dispatch
  6. A moving rectangle, where we draw things
  7. Sprites, where we create our player's ship
  8. Backgrounds, where we handle resizing, scale and translate through time
  9. Main menu, where we play with textures and Rust's vectors
  10. Asteroid attack!, where we render animated asteroids
  11. Shooting bullets, where we explore iterators
  12. Brawl, at last!, where we make objects interact and explode
  13. Boom! , where we play sound.
  14. Variety, where we create more enemies
  15. Difficulty, where we manage the difficulty level and the score
  16. High score & wrap-up, where we play with the file-system and enhance our main menu

This tutorial was written for people who are already somewhat familiar with the craft of software development, perhaps even through a scripting language, and who have just discovered this strange beast called Rust. They skimmed through the Book, read plenty of blog posts about how this familiar-looking language supposedly challenges all previous ideas about software safety and, excited, want to discover how Rust really works out in practice.

What I demand of the reader is that he or she (or it?) understands such concepts as interfaces, methods, conditional structures, and (basic) static typing. Most of the time, the meaning of these terms will be self-evident from the context. However, if these pose a problem to you, then be informed that I will not go to great lengths to explain them.

I also expect you to have already learned a bit of Rust prior to reading this tutorial, at least from a high level. For example, you must understand what Rust's use statement does, at least in the file, however there is no need to be an expert in the subject as we will discover its subtleties together.

In the next couple of weeks, we are going to build a simple space shooter based on Mike Geig's superb 2D Game Development Course, and a basic library called phi which will provide us with the basic components required by 2D games, such as views (called screens in LibGDX), rectangles with built-in (albeit basic) collision detection, and animated sprites.

The libraries we are going to use for that will be AngryLawyer's SDL2 bindings, version 0.13, which you can see here, and the associated plugins.

Before we continue, I want to stress that you do not need to have mastered Rust prior to reading this tutorial. On the contrary, exploring Rust's subtleties is one of its objectives, if not the main one because, let's be honest, I do not recommend to use phi in production. However, you need to have at least skimmed through the book or Rust by Example.

Basically, I will not explain the syntax, but how to use it to make things.

So, without further ado, let's get to it!

Legal stuff

After being asked about it a few times, I thought I'd include a little disclaimer:

You can use the code we're writing in this tutorial for whatever purpose you have, whether in a personal project or a commercial one.

I would like to note, however, that I do not encourage it — not because of copyright stuff, but simply because I'm building this project with pedagogy in mind, not performance or maintainability.

THIS DOES NOT INCLUDE THE GAME'S ASSETS, which I've mostly taken from google and Mike Geig's course to save time. I might bother to replace those by custom resources one day. Until then, though, you shouldn't use those in your projects, just in case.

Continue reading on