Space Invaders adaptation for a 16-Bit PIC microcontroller

A cover of the classic 1978 videogame Space Invaders, written in C for the 16‑bit PIC24FJ128GA010 and simulated in Proteus, with a T6963C‑driven 240×128 graphics LCD. Built with Mauricio Marcano for PG‑7233 — C for Embedded Systems.

Space Invaders running on the PIC24FJ128GA010, simulated on Proteus.

(video with increased speed)

Getting Started

Source Code

This project is hosted on GitHub. You can clone this project directly using this command:

git clone https://github.com/leonardoward/space-invaders-pic-proteus.git

Dependencies

The project only requires the following development environments:

• MPLABX
• Proteus

The Proteus project uses components included in the environment by default and does not require additional component imports.

Building

The building process is performed in the MPLABX development environment to generate the .hex file necessary for the Proteus Simulation. This is done by clicking the clean and build button in MPLAB.

Menu on MPLABX.

Setup

In order to run the simulation in Proteus, the user has to insert the .hex file path in the PIC preferences.

Component settings on Proteus.

Design and Architecture

PIC

This project was developed on the PIC24FJ128GA010 microcontroller.

LCD Screen

The LCD controller used was a T6963C to drive a screen of 240 x 128 pixels. In this project enhancements were made to the library T6963C_PIC of camilstaps in order to drive the screen.

Start animation of the game running on the 240x128 LCD.

(video with increased speed)

Buttons

The buttons used were three push buttons native of proteus in pull-up configuration, two of them for lateral movement and the other one to shoot.

Pull up circuits on the Schematic.

Two Way Render

The way the invaders render is variable: When the invaders move from right to left the rendering direction is from left to right, and vice versa. This mechanism allows collision detection to be performed on the outermost invader only once at the beginning of the update cycle, regardless of the number of live invaders.

Game render.

(video with increased speed)

Custom Made Sprites

In order to draw in the screen with the T6963C symbol generator, custom 8x8 sprites were made for each character in the game. The three types of invaders sprites were implemented with their respective four animations:

1. Position 'a'.
2. Position 'b'.
3. Position 'a' dodging laser shot.
4. Position 'b' dodging laser shot.

The spaceship and mothership sprites, the barriers sprites with the ability to be destroyed with 3 hits, laser shots and explosion sprites.

Custom sprites.

The tool used to draw and export the images was Piskel, and the tool used to generate the array files from the bitmap pictures was LCD Assistant.

Space Invaders running on the PIC24FJ128GA010, simulated on Proteus.

(video with increased speed)

Game Logic

Attack intelligence for invaders has been implemented to spice up the gameplay. Also collision detector alien/barrier and collision detector alien/spaceship, live and score systems, and game over/restart screen were implemented.

Gameplay video.

(video with increased speed)

Game Architecture

We implemented the game using 4 basic design patterns:

• Game loop: the main loop contains an inner loop that manages the inputs, the update of each component and the rendering of each component. The objective of this pattern (process input -> update -> render) is to decouple the progression of the game from user input and processor speed. We managed to decouple it from the user input but not the processor speed, right now it will run at maximum speed.
• Update Method: each game component has an update method that processes one frame at a time.
• Component: each game object (spaceship, invader, mothership, bullet and barrier) is a single entity that can be spawned across multiple domains (locations) without coupling the domains to each other. We also use the Prototype pattern, we can create different versions of the game object by creating different instances of the same structure.
• State: each component has a state, and it is often used to define if the type of animation has to change or if it should be removed from the game.

The following image presents a Flowchart of the game.

Software Block Diagram.

We implemented different structures to solve specific problems that arise during development, we will describe a little bit more about them in the following sections.

Animation of a Single Game Object

We are using Singly Linked Circular Lists to manage the animations of the game objects. We only required one or two sprites, but the list is also very convenient during the rendering phase.

Animation List.

Animation of a Group of Invaders

The invaders have a different rendering order depending of the direction in which the group is moving:

Alien List.

• If the group is moving from left to right, it will render the invader from right to left depending on its position in the group. From "Tail Vertical" to "Head Vertical" in the image.
• If the group is moving from right to left, it will render the invader from left to right depending on its position in the group. From "Head Vertical" to "Tail Vertical" in the image.
• If the group is moving from top to bottom, it will render the invader from bottom to top depending on its position in the group. From "Head Horizontal" to "Tail Horizontal" in the image.

Game Map

To detect the collisions between game objects we created a game map, a 2D array with the size of the screen where each element contains a pointer to the game object that is associated to that X Y position. This map is updated with each frame according to the new positions of the objects.

Game Map.

Simulation

In the following video you can see the gameplay of this Space Invaders cover in Proteus Simulation.

At the beginning the landing page is shown, then the user can use the buttons to play the game.

Video of the game Space Invaders running on the PIC24FJ128GA010 microcontroller.

Future Improvements

Integrate audio to gameplay, this was tried without success in another project (mplab_audio) using the "output comparator interruptions" of the PIC to generate a PWM signal that later in Proteus is filtered to get the sound. The main problem encountered was the delay of the Proteus Simulation.

The sounds used were from the original game released in 1978 by Taito (available here), and converted to array with the tool WAVToCode by Colin Seymour.