Programming Pixels

Fly Everything devlog #2 - Control schemes

2019-10-29T00:00:00+01:00

The previous devlog is available here

I started trying to add more object types to the game as well as a very basic menu system that would be useful for testing during development. Like the prototype, touching anything other than platforms will kill the drone, there's a large orange barrier in the centre of the level and I fenced the whole screen in with a kill barrier around the edge.

Your browser does not support the video tag.

One of the key differences I wanted between this and the game jam game that inspired it was larger levels. To accomplish that I'd need to have a camera able to follow the drone around a larger level. The game is supposed to have more of a problem solving feel than an action/ adventure title so I made a little camera zoom intro that shows the player the whole level before they start.

Your browser does not support the video tag.

Moving platforms seem to be working correctly now but they were a real pain again. The theory sounds simple, when the drone lands on the platform, move the drone with platform.

I may make a godot tutorial in the future to cover moving platforms because it doesn't seem to be a well covered topic. I have a few added complications here that I think most games don't have to deal with:

Platforms can move in any direction.
It's only safe for the drone's feet to touch the platform. If any other part of the drone touches it then the drone is considered to have crashed.
Making contact with only one foot is considered a crash.

Fly Everything devlog #1 - Control schemes

2019-10-22T00:00:00+02:00

Real work on the project has begun and there are some basic assets and gameplay in place. I had the idea that the drone could be controlled with a single touch on the screen by having the drone fly towards the location of the touch.

Your browser does not support the video tag.

User testing uncovered a number of problems though:

Because gravity is constantly pulling the drone down, the player need to touch somewhere above the drone every second or so to prevent it falling to the bottom of the screen. This means that the players hand often blocks their view of the screen.
Can't easily navigate around the top section of the screen as you need to touch above the drone to maintain it's height.
It's uncomfortable to have to hold a phone/ tablet with a single hand which the player is required to do as one hand needed to touch anywhere on the screen.

To tackle these problems I changed to a safer and more familiar control layout and add buttons to the screen.

Your browser does not support the video tag.

The biggest problem with button style controls on a touchscreen is the lack of tactile feedback. When you use a console controller you're constantly receiving feedback through your thumbs about where they are on the controller- if you miss a button you can feel that you haven't pressed anything. You don't have that on a touch screen though. To counter this, I've actually made the effective button area much much larger than the button images on the screen. Touching anywhere in the shaded blue area will actually trigger the button.

Hopefully progress on new features will be rapid now I've settled on a control scheme.

The next devlog is available here

Fly Everything devlog #0

2019-10-15T00:00:00+02:00

Last month I had a lot of fun doing a game jam, you can read about the game and my experiences here. I decided to take the concept and turn it into a full-blown mobile game. I'll be doing devlogs here but they'll probably lag a little behind my twitter where it's easier to post short updates so follow me on there if you want to keep up to date with the latest developments.

Before diving into mobile development, I decided to go back and add an extra 'final' level to the prototype. The whole game is completely free to download for windows and linux on itch.

Just publish it to mobile stores then

Unfortunately the support for getting pygame applications onto mobile platforms is limited. There are libraries out there that would help get it onto android but from what I've read support for ios is lacking. Pygame is a great tool and obviously by using it you have the power of python and its extensive collection of 3rd party libraries. In this case though building a small game targeting mobile first, it seems like Godot would be a much more sensible choice. It has a lot of built in support for deployments to mobile platforms and rebuilding what I've already done in python will only take a few days.

It's pretty small even for a mobile game

I haven't created a game for mobile for quite a few years so it'll be good to get the ball rolling again with something small but I do have a number of improvements in mind. Firstly, the working title is 'Fly Everything'- I want to include three or four aircraft types (like stunt planes and space shuttles) including my original drones. A rough wishlist looks like:

More aircraft types.
Improved artwork and animations.
Higher resolutions than 64x64.
At least 10 levels for each aircraft type.
Larger levels so that the camera will have to move to follow your aircraft.
Many more obstacle types.
A choice of intuitive touch screen control methods.

When

It's not a huge project and even though I'm going to improve the artwork, I'll be keeping it quite basic. The target for release is November 2019.

The next devlog is available here

Drone pilot - Lowrezjam 2019

2019-09-27T00:00:00+02:00

The 2019 lowrez game jam took place in august this year. Unfortunately I was busy at the time and even though the jam lasted for eighteen days I could only use the last three!

If you want to try the game yourself you can download it for free from itch.

Rules and Restrictions

Themes are provided but they're not mandatory, you can make whatever kind of game you like but it cannot have a higher resolution than 64x64 (it can be stretched to fit modern screens). There were a few ideas that I thought were doable in the time I had left but had to be thrown out once I realised that they just wouldn't be playable at that kind of resolution.

Basic Gameplay

Blue and green platforms are both safe to land on but to complete the level you must land your drone on the green platform. When a platform turns red it indicates that your approach velocity to it is too fast, if you land at this speed you'll crash and fail the level. The orange warning light in the bottom right also indicates that your approach to the target (green) platform is too fast.

Other ways you can fail the level are:

Any red border or wall will kill you if you make contact.
Touching a platform with any part of your drone other than the bottom.
Colliding with another drone.

Your fuel bar is shown in purple at the bottom of the screen and when it runs out you'll lose control of the drone.

If you want to try the game yourself you can download it for free from itch.

Brainstorming

Originally I decided to try and build a game where you had to land a space shuttle on a platform. I wanted to have classic asteroids style controls (that's rotation and thrust) but then also add in gravity. I tried knocking up a few ships in a sprite editor and quickly realised that with the limited number of pixels it would be impossible to have a rotating shuttle that looked like it was responding properly to controls. I decided I'd change the idea to controlling a drone which would have more limited controls (up, left and right but no rotation) and this would make the 'art' clearer as I could just use a few different sprites to indicate direction.

Step by step not giant leaps

In a local game jam I did earlier in the year I had absolutely nothing working until a few hours before the deadline- that turned out to be an extremely stressful development process. There were two main reasons why that happened: one of the team members turned out to be much less available than he hoped and it was the kind of game where nothing worked until everything did. We didn't build it by taking small steps but instead by trying to take one giant leap.

I didn't want to build another game in this way and wanted to build a level based game where I could work on a feature, add it to a level and then move on to the next. Introducing a new game mechanic with each level.

Making this game was quite a straight forward process, especially getting started because all I needed was a moving drone body in an empty screen.

Rough order of development was:

Platform collision.
Kill zone at the edge of the screen.
Kill drone if platform collision was too rough.
Add new mechanic for the next level.
Repeat 4.

Often, the small games we make have a single concept or level idea. I wanted to try and make a game where I could experiment a bit with level design. I think you can see the iterative approach below, where each level only introduces one new mechanic. The gifs below are me completing each level in practice mode.

Unfortunately in the end I just couldn't get it all wrapped up and submitted by the deadline with adequate instructions and bug free gameplay (in particular, riding moving platforms turned out to be a pain). I am pleased with the end result and getting to experiment with level design on a short project like this was a lot of fun. Usually with jams like this it can be tempting to focus on a single gameplay element and level.

The limited resolution posed an interesting problem, how to communicate information to the player in a clear but unobtrusive way and I had to quickly throw away the idea of having a 'proper HUD' for the drone.

It would have been really nice to do more than 8 levels and I had a lot of ideas for other mechanics I could add to the game but once I realised I'd missed the deadline it ruined my motivation to really do something bigger with the project.

If you want to try the game yourself you can download it for free from itch.

Handling a title screen, game flow and buttons in pygame.

2019-09-12T00:00:00+02:00

Pygame has no built in UI components

Without buttons it can be difficult to handle title screens, game menus and the general flow of the game from one stage to another. There are a few libraries for creating ui elements that are designed to work with pygame but many of them are abandoned and if you do find one in development you'll have to conform to its conventions. Fortunately it's not difficult to make your own buttons and menu system, and if you do you'll retain complete control over the way your game runs.

There's a lot of really fancy menu design in games now, menu items can be buttons with backgrounds, text that changes shape and/ or colour when selected etc. We're not going to go over every possible effect that a UI element could have but instead we're going to focus on getting something basic working that can be easily built on so we can also cover how these UI elements can fit neatly into our game's logic.

We're going for simple interactive elements that are text only and increase in size a little when selected. All steps shown in this tutorial are included in this gist.

Step 1: Responsive text

We'll start by making text that responds when the mouse is over it. Here's what we should have at the end of this step.

We'll need some imports, the rgb values of few colours for convenience and a small helper function that renders text onto a surface. (The convert_alpha method is a small optimisation that enables the surface to be more quickly blitted to the screen).

import pygame
import pygame.freetype
from pygame.sprite import Sprite
from pygame.rect import Rect

BLUE = (106, 159, 181)
WHITE = (255, 255, 255)


def create_surface_with_text(text, font_size, text_rgb, bg_rgb):
    """ Returns surface with text written on """
    font = pygame.freetype.SysFont("Courier", font_size, bold=True)
    surface, _ = font.render(text=text, fgcolor=text_rgb, bgcolor=bg_rgb)
    return surface.convert_alpha()

For our UI element we're going to create a subclass of pygame's Sprite class, this means we can render them with pygame's sprite render classes if we want to but we'll also add a draw method in case we don't (we won't use them until the very end). In the init method we'll create images for the button when the mouse is over and when it isn't.

class UIElement(Sprite):
    """ An user interface element that can be added to a surface """

    def __init__(self, center_position, text, font_size, bg_rgb, text_rgb):
        """
        Args:
            center_position - tuple (x, y)
            text - string of text to write
            font_size - int
            bg_rgb (background colour) - tuple (r, g, b)
            text_rgb (text colour) - tuple (r, g, b)
        """
        self.mouse_over = False  # indicates if the mouse is over the element

        # create the default image
        default_image = create_surface_with_text(
            text=text, font_size=font_size, text_rgb=text_rgb, bg_rgb=bg_rgb
        )

        # create the image that shows when mouse is over the element
        highlighted_image = create_surface_with_text(
            text=text, font_size=font_size * 1.2, text_rgb=text_rgb, bg_rgb=bg_rgb
        )

        # add both images and their rects to lists
        self.images = [default_image, highlighted_image]
        self.rects = [
            default_image.get_rect(center=center_position),
            highlighted_image.get_rect(center=center_position),
        ]

        # calls the init method of the parent sprite class
        super().__init__()

We'll add a few properties to the class that change values depending on whether mouse_over is true or not.

# properties that vary the image and its rect when the mouse is over the element
@property
def image(self):
    return self.images[1] if self.mouse_over else self.images[0]

@property
def rect(self):
    return self.rects[1] if self.mouse_over else self.rects[0]

To finish off the class add update and draw methods to the class. All the update method does for now is sets the mouse_over value depending on whether the user's cursor is over the text or not.

def update(self, mouse_pos):
    if self.rect.collidepoint(mouse_pos):
        self.mouse_over = True
    else:
        self.mouse_over = False

def draw(self, surface):
    """ Draws element onto a surface """
    surface.blit(self.image, self.rect)

Now to a button and game loop where we update the ui element with the current mouse position.

def main():
    pygame.init()

    screen = pygame.display.set_mode((800, 600))

    # create a ui element
    uielement = UIElement(
        center_position=(400, 400),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Hello World",
    )

    # main loop
    while True:
        for event in pygame.event.get():
            pass
        screen.fill(BLUE)

        uielement.update(pygame.mouse.get_pos())
        uielement.draw(screen)
        pygame.display.flip()


# call main when the script is run
if __name__ == "__main__":
    main()

That's step 1 complete. If running your script doesn't give you the same result as the gif shown at the start of this step then compare your script to this gist.

Step 2: Handling clicks

In step 1 the text increases in size when you mouse over to indicate that it's interactive but clicking it doesn't actually doing anything yet.

In this step we're going to make our buttons responsive to mouse clicks and create a quit button that closes the application. Here's what we should have at the end of this step.

A short aside: Some people advocate for sending a function as an argument to a button (that is a function name without brackets) so that on a click event, the button can call the function. That's ok for short running functions (say for instance that you just want to add some score every time you click on the button) but you don't want to have a button calling a function that changes the level, or goes back to the main menu because the button will remain in the heap since you are still in one of its functions. As you press more and more buttons your application will have to retain all button instances in memory and store other objects that were loaded in the pursuit of loading more buttons (level instances etc.).

I prefer to use enums to move between game states, so we will pass in enum values when the button is created and check for state changes in a little loop.

Don't worry if that's not very clear yet, it should become clear as we work through this step.

Add Enum to our list of imports at the top of the file.

from enum import Enum

Add an action argument to the init method of the UIElement, the method declaration should look like this

def __init__(self, center_position, text, font_size, bg_rgb, text_rgb, action=None):

At the bottom of the __init__ method, assign action to an instance variable

self.action = action

We need to change the update method of the UIElement to check for mouse clicks, we'll do that by passing in a value for mouse_up when we call the button's update method. When the mouse is clicked on an element, the element returns the value stored in it's action variable.

def update(self, mouse_pos, mouse_up):
    """ Updates the element's appearance depending on the mouse position
        and returns the button's action if clicked.
    """
    if self.rect.collidepoint(mouse_pos):
        self.mouse_over = True
        if mouse_up:
            return self.action
    else:
        self.mouse_over = False

Create and enum class with one possible action: Quit.

class GameState(Enum):
    QUIT = -1

We need to change the main function to add a quit button. In the main loop the pygame event queue is checked to see if the primary mouse button has been clicked (we're using the mouse up event which fires after the mouse button has been pushed down and then released 'up'). The mouse position and the mouse_up status are then passed into the update function of the button. If the button has been clicked, the update function will return a GameState enum value, since there's only one possible GameState that could be returned (quit) we stop the application.

def main():
    pygame.init()

    screen = pygame.display.set_mode((800, 600))

    quit_btn = UIElement(
        center_position=(400, 500),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Quit",
        action=GameState.QUIT,
    )

    # main loop
    while True:
        mouse_up = False
        for event in pygame.event.get():
            if event.type == pygame.MOUSEBUTTONUP and event.button == 1:
                mouse_up = True
        screen.fill(BLUE)

        ui_action = quit_btn.update(pygame.mouse.get_pos(), mouse_up)
        if ui_action is not None:
            return
        quit_btn.draw(screen)
        pygame.display.flip()

That's step 2 complete. If running your script doesn't give you the same result as the gif shown at the start of this step then compare your script to this gist.

Step 3: Add to the title screen and make a level

Our UIElement class is finished and working but our game still only has one screen and all you can do is quit. We're going to expand our example so we have a start button on the title screen as well as a quit and a return to main menu option in a level.

Start by adding all the options we'll need to the GameState enum.

class GameState(Enum):
    QUIT = -1
    TITLE = 0
    NEWGAME = 1

We're going to change our main function quite a lot, we are no longer going to load button objects in it. Instead it'll be used as sort of game state handling function, loading different functions that are called based on the current game_state. When buttons are pushed in the title_screen or the play_level functions, a new GameState value is returned.

def main():
    pygame.init()

    screen = pygame.display.set_mode((800, 600))
    game_state = GameState.TITLE

    while True:
        if game_state == GameState.TITLE:
            game_state = title_screen(screen)

        if game_state == GameState.NEWGAME:
            game_state = play_level(screen)

        if game_state == GameState.QUIT:
            pygame.quit()
            return

Now we need to create the title_screen function, much of this code should be familiar as it's very similar to what we used to have in main. We're going to make two buttons which update during every game loop. One has a NEWGAME action and the other QUIT. The game loop ends when one of the buttons is clicked and the action value from the button is returned to the main function.

def title_screen(screen):
    start_btn = UIElement(
        center_position=(400, 400),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Start",
        action=GameState.NEWGAME,
    )
    quit_btn = UIElement(
        center_position=(400, 500),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Quit",
        action=GameState.QUIT,
    )

    buttons = [start_btn, quit_btn]

    while True:
        mouse_up = False
        for event in pygame.event.get():
            if event.type == pygame.MOUSEBUTTONUP and event.button == 1:
                mouse_up = True
        screen.fill(BLUE)

        for button in buttons:
            ui_action = button.update(pygame.mouse.get_pos(), mouse_up)
            if ui_action is not None:
                return ui_action
            button.draw(screen)

        pygame.display.flip()

Similarly, we're going to make a play_level function that will act like the first level of our game. The level will have one button to return to our main menu and nothing else.

def play_level(screen):
    return_btn = UIElement(
        center_position=(140, 570),
        font_size=20,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Return to main menu",
        action=GameState.TITLE,
    )

    while True:
        mouse_up = False
        for event in pygame.event.get():
            if event.type == pygame.MOUSEBUTTONUP and event.button == 1:
                mouse_up = True
        screen.fill(BLUE)

        ui_action = return_btn.update(pygame.mouse.get_pos(), mouse_up)
        if ui_action is not None:
            return ui_action
        return_btn.draw(screen)

        pygame.display.flip()

That's step 3 complete. If running your script doesn't give you the same result as the gif shown at the start of this step then compare your script to this gist.

Step 4: Using sprite renderers, storing player attributes and tidying up

Our code is starting to look useful but in a real game we might want to keep track of things like which level the player is on, how many lives they have or what their score is. We'll add that in now as well as replace our manual draw calls with a sprite renderer that will handle the drawing of all our buttons. Here's what we should have at the end of this step.

First we need add one of pygame's sprite renderers to our list of imports.

from pygame.sprite import RenderUpdates

Then we'll add a data class to store some player attributes.

class Player:
    """ Stores information about a player """

    def __init__(self, score=0, lives=3, current_level=1):
        self.score = score
        self.lives = lives
        self.current_level = current_level

In the main function we want to create a player instance before we start a new game and add a game state check for when we need to move to the next level.

if game_state == GameState.NEWGAME:
    player = Player()  # new line
    game_state = play_level(screen, player)

# new block
if game_state == GameState.NEXT_LEVEL:
    player.current_level += 1
    game_state = play_level(screen, player)

To help tidy up our title_screen and play_level functions make a game_loop function. This function manages the game loop until one of the buttons is pressed, at which point it returns the button's action value.

def game_loop(screen, buttons):
    """ Handles game loop until an action is return by a button in the
    buttons sprite renderer.
    """
    while True:
        mouse_up = False
        for event in pygame.event.get():
            if event.type == pygame.MOUSEBUTTONUP and event.button == 1:
                mouse_up = True
        screen.fill(BLUE)

        for button in buttons:
            ui_action = button.update(pygame.mouse.get_pos(), mouse_up)
            if ui_action is not None:
                return ui_action

        buttons.draw(screen)
        pygame.display.flip()

This function could be extended later to draw more objects but at the moment we only have buttons but it allows us to simplify some of our other functions. The title_screen function still has two buttons but now they're added to a RenderUpdates collection and game_loop is called with the result returned.

def title_screen(screen):
    start_btn = UIElement(
        center_position=(400, 400),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Start",
        action=GameState.NEWGAME,
    )
    quit_btn = UIElement(
        center_position=(400, 500),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Quit",
        action=GameState.QUIT,
    )

    buttons = RenderUpdates(start_btn, quit_btn)

    return game_loop(screen, buttons)

Add a player argument to the play_level function so that player data (current_level etc.) can be passed in. Add a new button to the play_level function and give it the action of next level. After button creation we just need to return the result of game_loop like in the title_screen.

def play_level(screen, player):
    return_btn = UIElement(
        center_position=(140, 570),
        font_size=20,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text="Return to main menu",
        action=GameState.TITLE,
    )

    nextlevel_btn = UIElement(
        center_position=(400, 400),
        font_size=30,
        bg_rgb=BLUE,
        text_rgb=WHITE,
        text=f"Next level ({player.current_level + 1})",
        action=GameState.NEXT_LEVEL,
    )

    buttons = RenderUpdates(return_btn, nextlevel_btn)

    return game_loop(screen, buttons)

That's the final step complete! If running your script doesn't give you the same result as the gif shown at the start of this step then compare your script to this gist.

How to consistently scale a pygame application to full screen

2019-09-03T00:00:00+02:00

What's the Problem?

While working on a game for the recent lowrez game jam I noticed pygame exhibiting some strange behaviour. My game ran correctly in window mode but when I switched to full screen the aspect ratio wasn't right. My square game window hadn't maintained it's original aspect ratio at full screen (which would have created black bars at the side of a square game window), nor had it been fully stretched to take up all of my widescreen monitor. It had done something in-between, creating black bars at the sides of my game that were an incorrect size.

To help investigate the problem, I wrote a very basic python script that uses pygame to draw a square in the top left area of the screen. I found that 16:9 monitors seemed to display a range of resolutions correctly while monitors with other aspect ratios (mine is 16:10) displayed rectangles instead of squares. (This was tested across windows and linux mint and several completely different monitors and machines running a mix of AMD and NVIDIA graphics cards).

These images are the result of the following function.

def fullscreen(game_height):
    """ Sets full screen display mode and draws a square in the top left """
    # game_height = game_width in a square
    screen = pygame.display.set_mode((game_height, game_height), FULLSCREEN)
    screen.fill((255, 255, 255))  # fill white
    pygame.draw.rect(
        screen,  # surface
        (0, 0, 0),  # rgb (black)
        Rect(10, 10, 200, 200))  # (x, y, width, height)
    pygame.display.flip()
    wait_for_keypress()

Generally I've found that pygame's default full-screen option doesn't reliably maintain your game's aspect ratio and may do something unpredictable (we should have squares in the images above and instead we have rectangles). The first monitor detects a 1280x1024 resolution which isn't native but should be supported by the monitor (pygame.display.list_modes() reports that 1280x1024 is a supported mode and windows 10 appears correctly on this monitor if set to that resolution).

There are other limitations to using pygame's default full-screen behavior, as it seems limited in its ability to stretch resolutions up to a factor of 2. If you make a game and want to support the popular laptop screen resolution 1366x768 then you won't want to make your game greater than 768 pixels high. But you can't scale that all the way to 4k (2160 pixels high) using pygame's default full-screen functionality.

When we distribute a game, we want to know our application's aspect ratio is going to be correctly maintained for a range of different set-ups and displays so we need a method to produce a consistent game experience for all our players.

Solution

One solution is to use pygame's scale method to scale our game surface up to the largest square that will fit on the monitor and then blit this surface to the correct location on a native resolution screen object.

def fullscreen_fix(game_height):
    """ Sets full screen display mode and draws a square in the top left """
    # Set the display mode to the current screen resolution
    screen = pygame.display.set_mode((0, 0), FULLSCREEN)

    # create a square pygame surface
    game_surface = pygame.Surface((game_height, game_height))
    game_surface.fill((255, 255, 255))

    # draw a square in the top left
    pygame.draw.rect(game_surface, (0, 0, 0), Rect(10, 10, 200, 200))

    # make the largest square surface that will fit on the screen
    screen_width = screen.get_width()
    screen_height = screen.get_height()
    smallest_side = min(screen_width, screen_height)
    screen_surface = pygame.Surface((smallest_side, smallest_side))

    # scale the game surface up to the larger surface
    pygame.transform.scale(
        game_surface,  # surface to be scaled
        (smallest_side, smallest_side),  # scale up to (width, height)
        screen_surface)  # surface that game_surface will be scaled onto

    # place the larger surface in the centre of the screen
    screen.blit(
        screen_surface,
        ((screen_width - smallest_side) // 2,  # x pos
        (screen_height - smallest_side) // 2))  # y pos

    pygame.display.flip()
    wait_for_keypress()

Now we've maintained our game resolution and aspect ratio (our code draws squares and our monitor is showing squares).

This method should work for all resolutions and screen orientations (landscape or portrait). Testing this with a few games I've written, the scaling takes around 2ms each frame on my modest machine (in a 60fps game, you have 16.67ms per frame).

The code snippets used in this post are available in full at this gist.