DEV Community: Braeden Richards

Forest Defender Devlog 2: Basic Camera and Movement

Braeden Richards — Fri, 28 Oct 2022 17:59:12 +0000

Forest Defender Devlog 2: Basic Camera and Movement

Written on October 28th, 2022

Preface
- General Accomplishments
- Why movement and camera motion is so important
Movement
Gravity and Collisions
- Gravity
- A bit about aspects
- Collisions
- Other Additions
Camera Enhancements
Finishing Notes
Resources / Further Reading

This week's results of development. Each piece will be explained below.

Preface

General Accomplishments

Since the previous devlog, Forest Defender: development setup, a lot of groundwork has been completed.

We now have created a simple tileset. After some searching for a nice but small color palette, we settled on using the Wild Jungle Color Scheme as it had the right feel of jungle vibes. It is also very narrow in its color range, really just being brown and green, which is exactly what we were looking for. I am a big fan of games built around minimal color differences since it reminds me of original Nintendo GameBoy games. In the created tileset, you can see we have just a handful of tiles to start with and two entities: a mushroom entity and the player. These will be expanded into animations later on.

We then took that tileset and created a basic testing level for movement by using Tiled. Building the level is easy and there are plenty of tutorials for reading the export from Tiled into a Python project via a custom import function. I will have a couple tutorials and examples linked in the further reading section at the end of this devlog.

Once the level was created, we plopped in our player's character and added in some gravity and controls. Using force based physics, it is easy to tweak movement to feel just right. We also added in a nice camera to follow the player around to get the first steps of this project complete. I have detailed how I did these movement and physics additions in the following sections.

Why movement and camera motion are the most important piece of a game

General motion of the game (camera and player movement) is often overlooked by first time game developers. Many people either put in a simple system early on and work on improving it later in development, or they just use an out of the box solution. In my opinion, general motion is the most important part of a game and should be designed and made as perfect as possible for your end goal at the beginning of development. I am willing to play most games with great motion feel regardless of graphics, animation, etc. but I will usually get frustrated in a game if there are lots of collision problems, clunky movement, etc. even with beautiful graphics.

Let's start with what makes good movement in a game. In general, good movement refers to smooth motion, intuitive controls, and accurate collisions. Since there are various types of games, all with different ideal movements, let's just focus on our Forest Defender game.

Since our game is 2-D, collisions are pretty easy. We really only need to worry about vertical collisions and horizontal collisions. We aren't going to have any tiles with special collision properties (such as steep slopes), so there isn't much more to plan for.

Our character is a 'fairy' type creature, so we designed the sprite with wings. While this won't help the fairy fly, this helps the character not fall too quickly and lets the player change direction mid-air. Therefore, when the character is falling or has jumped we want the player to be able to still move the character left and right just like the player was still on the ground.

Camera movement comes in too many varieties to describe them all. For our game, we are going with a simple camera movement. Essentially, when your character moves right, the camera moves right. When your character moves left, your camera moves left, etc. The biggest quality of life enhancement we are making to the camera is to give it a slight delay in its movement by using forces on the camera. This gives the camera a smoother look instead of jarring motion. This will be described more further down in this devlog.

Movement

The goal of our character movement is to be smooth and intuitive while fitting the character design.

Keeping motion smooth is generally easy. We will be using a force based system. So if the player presses the key to move right, a force will be applied to the character and it's acceleration will raise. The acceleration is then applied to the character's velocity each frame, which will move the character's position. The calculations are below, with dt being the time between last frame and current frame to make sure this process is frame-rate independent:

force = 1 * dt
acceleration = acceleration + (force * dt)
velocity = velocity + (acceleration * dt)
position = position + (velocity * dt)

Gravity and Collisions

Gravity

Gravity as a concept in 2-D physics is relatively straightforward: if down in the window is the ground, that is where the acceleration of gravity will point.

To add gravity to our character (and any future entities), we will include it as an aspect. An aspect is essentially an additional property you can add to an entity in the Python game engine we are creating for this project. To explain it simply, each entity can have 0+ aspects that it runs through each frame of the game. These aspects can be for animation, physics, random checks, etc. We could create each of these as their own function or class, but that would make our entity class contain many properties that need to be maintained and entered individually. Instead, we can have a base aspect class that other classes, like our gravity or physics movement, can inherit from. Then, we can simply add this new aspect into a list of aspects the entity holds onto and runs through each frame. Much easier and cleaner!

Back to gravity. Since in our game gravity will always be pointing downward in the window, we can just give the gravity acceleration a positive y value. This is because in Pygame, downward is a positive value and upward is a negative value. You will notice I mentioned giving gravity a positive acceleration, not a force. This is due to gravity being a constant, and therefore the acceleration never changes.

To add our gravity in, we do a calculation very similar to the calculation for our movement, since it is essentially the same thing:

acceleration.y = acceleration.y + (gravity * dt)
velocity.y = velocity.y + (acceleration * dt)
position.y = position.y + (velocity * dt)

Here we only modify the y value of the vectors since gravity only affects the player's vertical position. The result can be seen in the GIF below:

Collisions

Collisions can become as complicated as you need them to be. For us, collisions will be on the simpler side. We will only be adding vertical collisions and horizontal collisions. Put even simpler, checking if an entity hits an object with the top of its head or the bottom of its body, or if it hits an object with the left or right side of its body.

While it sounds easy and simple, the code for this still looks a bit complicated. In the code snippet below, we are adding the movement to the entity in the x and y directions, then checking if it is within (therefore hitting) another object. For checking if there is a hit, we are using Pygame's built in sprite hit detection function colliderect. In the snippet, this is called with self.get_hits(tiles) which is a wrapper function I wrote and is included below.

If there was a collision detected with the entity, we add that hit to the collision_type dictionary to be referenced later in repositioning the entity so they are just outside the collided object (therefore colliding instead of going through). We also modify the velocity of the entity so the entity loses its inertia upon a collision.

The code we used for now is as follows:

    def get_hits(self, tiles) -> list:
        hits = []
        for tile in tiles:
            if self.entity.rect.colliderect(tile):
                hits.append(tile)
        return hits

    def move(self, rect, velocity, tiles, dt):
        collision_types = {"top": False, "bottom": False, "right": False, "left": False}
        rect.x += velocity.x * dt
        hits = self.get_hits(tiles)
        for tile in hits:
            if velocity.x > 0:
                rect.right = tile.rect.left
                velocity.x = 0
                collision_types["right"] = True
            elif velocity.x < 0:
                rect.left = tile.rect.right
                velocity.x = 0
                collision_types["left"] = True
        rect.y += velocity.y * dt
        hits = self.get_hits(tiles)
        for tile in hits:
            if velocity.y > 0:
                rect.bottom = tile.rect.top
                velocity.y = 0
                collision_types["bottom"] = True
            elif velocity.y < 0:
                rect.top = tile.rect.bottom
                velocity.y = 0
                collision_types["top"] = True
        return rect, collision_types, velocity

Other

Besides the above mentioned additions to the game, we mainly added quality of life additions. These mainly include applying maxes to velocity so the player can't move infinitely fast, a slight delay allowed when jumping i.e. you can be a few frames off a platform (like walking off) and still be able to jump, which improves the feeling of the game, and small force tweaks.

The applying of maxes is simple, as shown below:

    def apply_maxes(self) -> None:
        if self.entity.velocity.x > self.entity.max_speed.x:
            self.entity.velocity.x = self.entity.max_speed.x
        elif self.entity.velocity.x < -self.entity.max_speed.x:
            self.entity.velocity.x = -self.entity.max_speed.x

        if self.entity.velocity.y > self.entity.max_speed.y:
            self.entity.velocity.y = self.entity.max_speed.y
        elif self.entity.velocity.y < -self.entity.max_jump_speed:
            self.entity.velocity.y = -self.entity.max_jump_speed

Camera Enhancements

Basic camera movement is easy to implement. Simply place your camera's center position on the player character at the end of each frame when all the updates are done. This leads to harsh behavior of the camera though. The motion of the camera would feel jarring when changing directions.

We resolved this by instead applying forces to the camera for movement. Essentially we take the difference in position between the player's center and the camera's center positions and apply that to the default force applied to the camera. This means the further away the camera is from the player, the faster the camera will move toward the player. This is done easily in the code:

self.position.x += (
            player.rect.centerx - (self.position.x + self.width / 2)
        ) / 5
self.position.y += (
            player.rect.centery - (self.position.y + self.height / 2)
        ) / 5

This gives a sort of 'lag behind' motion of the camera that smooths any jarring movements. You can see that in the GIF below.

You can see that instead of the camera being exactly on the player at all times, the camera sort of 'lags' behind the player. The distance * force feature we have added means the camera will never fall too far behind.

Finishing Notes

That is about all that was completed during this last bit of development. I will try to get these blogs out at least every two weeks, though the next few may be quicker since I have a lot of development worked on and just need to get it into devlogs.

If you have any questions, feel free to leave a comment and I will do my best to answer it!

Resources / Further Reading

Reading from Tiled into Python

Resources for Physics

Other

Forest Defender Devlog 1: Development Setup

Braeden Richards — Wed, 26 Oct 2022 21:35:08 +0000

Forest Defender Devlog 1: Development Setup

Image by storyset on Freepik

Written on October 25th, 2022

Preface
Development Machine
Development Tool Installation / Updating
Virtual Environment
Installing Libraries
Checking Everything Works!
Resources / Further Reading

Preface

The goal of this devlog is to show how I set up my environment for development of this game. Future devlogs will focus on higher level topics, such as game development updates, topics and discussion of the game, etc., instead of lower level topics like this devlog.

That is not to say I won't go into any details / code in future devlogs. If there is an interesting challenge I face or a topic I think is helpful to explain or show, I will certainly add it to the devlog.

What will be used as the development machine?

The development machine chosen to create a game is important as it sets the main target OS for the game build, creates the subset of tools that can be used, and sets the development environment as a whole.

My development machine is a Windows 10 desktop computer. The specifications are as follows:

Motherboard: ASUS ROG STRIX Z390-E Gaming
Processor: Intel Core i9 9900k
RAM: 32GB of CORSAIR 3.0GHz DDR4
Storage:
- Samsung 970 EVO Plus 500GB
- Samsung 970 EVO Plus 500GB (second one)
- Western Digital 1TB Hard drive
Graphics Card: NVIDIA GeForce RTX 2080 SUPER

This machine is certainly overkill for any development we are doing at this scale, especially since we are working on a 2-D game using Python. The machine also serves as a gaming computer for me, which is why these are its specifications.

Since I am using Windows 10 as my development OS, we are locked into tools that are available on Windows 10. While this does cut off a lot of Linux tools, we are still left with plenty. We are also locked into targeting Windows 10 for the main audience for the game. Python and the libraries we are using are able to run on the three major operating systems (Windows, macOS, Linux), but we will be testing and developing on the above system, so any testing on Linux and macOS will come at the end of development.

Ultimately, this is perfectly fine since most games are released on Windows versus the other operating systems and therefore most gamers use Windows to play games. So our audience is still the biggest 'chunk' of people.

Development Tool Installation / Updating

We won't be needing too many tools to get started with this project. We will install the following:

VS Code will be used as our text editor of choice. This is for planning of the game, project file management, and writing the actual code.

Aseprite will be used to create all the assets for the game, including the animations.

Tiled is our choice for taking those assets created in Aseprite and using them to create levels.

Virtual Environment

We want to keep our environment (module installations, Python version, etc.) separate from the OS wide installations. In order to do so, we need to create a separate container to store the environment. The way we will achieve this during this development run will be with Python's Virtual Environment.

It is extremely easy to setup. Ensure you have some version of Python 3+ installed on your machine, and run the following in the terminal / CMD:

> python -m venv env

In this command, we are telling Python to run the venv command, which creates a virtual environment in the current directory, and call it 'env.'

To enter the virtual environment while in the Windows OS, simply traverse to the directory containing it and enter:

> env/scripts/activate

Installing Libraries

To get started with the game, we don't need too many libraries. For now, we will only be using Pygame.

> pip install pygame

Checking Everything Works!

Now that we have the environment setup, all that is left to do before beginning with development is make sure it all works. We will be checking that the Python environment and Pygame installation were properly done. To accomplish this check, we will run the below Python script which opens a Pygame window:

import pygame

background_color: tuple[int, int, int] = (255, 255, 255)
width: int = 300
height: int = 200
window_title: str = "Window Test"

def main():
    screen = pygame.display.set_mode((width, height))
    pygame.display.set_caption(window_title)
    screen.fill(background_color)

    pygame.display.flip()

    keep_running: bool = True
    while keep_running:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                keep_running = False


if __name__ == "__main__":
    main()

When the above script is run, the following window appears:

Resources / Further Reading

Text Editor

Other

Pygame: Can you make an industry-standard game?

Braeden Richards — Fri, 02 Sep 2022 18:36:48 +0000

Pygame: Can you make an industry-standard game?

Written on May 10th, 2022

What is Pygame?

Pygame is a game framework available for use in Python3. You may notice that I called it a framework, not a game engine. Pygame is a set of modules that act as a wrapper around SDL (Simple DirectMedia Layer). This differs from a Game Engine which generally provides a GUI, pre-built game resources, etc. for the user.

As a game framework for Python, Pygame makes window creation, sprite management, controls mapping, and more much easier for the user. I will have a series of development blogs posted on this site to show how to take advantage of Pygame's strengths to develop a bullet-hell style platformer from planning to release.

Example of bullet hell game (Enter the Gungeon)

Let's talk Python

Python is known as either a godsend or slow language depending on the software developer asked. In the end, it is a tool that is amazing at some tasks and lackluster in others just like any other language. Python is generally not the first choice when creating a video game. However, with today's common computing power and C-based modules like Pygame available, Python can be plenty capable when it comes to creating a 2-dimensional game.

Example of Pygame created game (Shifting Edge)

Games with less assets on the screen work best for Python and Pygame. A bullet-hell genre game breaks this "light rule" since by definition it contains many assets (bullets and enemies) on screen at once. This leads to an interesting project / challenge since we will need to be careful to design a well-optimized entity manager and particle effects (which will be talked about more in the next section).

Python is also plagued with the GIL, or Global Interpreter Lock, which limits the number of cores useable by a Python application to 1. Therefore while multi-threading can still function (all on a single core), multi-processing is not possible in Python without having multiple applications running with the multiprocessing library, which is out of scope of this dev blog. Pygame gets around this problem by 'unlocking' the GIL - something that is only possible using the C language in modules.

So then why will we be using Python for this game? Well, Python is still a strong and mature language with many pros to it. Python has been around since 1991, and in that time a tremendous community has grown that has built many modules and documentation - making Python extremely powerful. Python's relative 'slowness' as a language also stems from pros of the language: being easy to write (no pointers / low level memory management), no compiling required (due to being an interpreted language), and ease of startup (from starting a project to having a running version).

Understanding of basic optimizing

We have discussed some high-level cons of using Python, so how will we get around it?

Let's start with the GIL. As mentioned above, this won't be an issue since Pygame actually gets around this. Pygame is also designed to be used without any threading by the user, so as far as thread/core management needed by us - there is none!

Next we have the relative slowness of Python. Our game will be doing some demanding stuff for an application: calculating, rendering, and modifying many objects each frame while aiming to maintain a 60 fps (frames per second) minimum on an average computer. Part of the solution, as mentioned above, is Pygame. But Pygame doesn't solve the rendering of text quickly, particle and entity management, etc. for us. For this, we will:

build a custom entity manager
build a custom font / text renderer
build a custom particle system
build any C modules as needed

This is by no means the only custom or optimized pieces we will create, but it will be the most important when it comes to performance.

A custom entity manager will allow us to choose what is being rendered / updated to the screen and how often that occurs. It will also allow us to use Python's strong list / dict comprehension to maintain integrity of the data while still doing all we need to do.

A custom font / text renderer is needed because (this may come as a surprise to many) text rendering is one of the tougher / time consuming processes for a game. Pygame has a text system built in to present text to the screen, but this requires the full string texture to be updated and re-rendered each update to the text. Instead, we will build a system that only creates the textures for rendering once for each symbol and will then blip this to the screen to create text. Since creating those textures is a heavy process, this will greatly increase the capabilities of our game.

Pygame doesn't have a particle system, so we need to create our own. Creation of any large number of entities brings the potential for poorly written code to slow down the game. Thankfully, we will be able to create a particle system that looks nice, functions according to the requirements we set, and is optimized enough to be used in our game.

Lastly, I suspect we can write 100% of our game in Python. However, if we run into some calculation or function that is unable to meet our speed goals, we can always create a C module. Even if this is not needed in the end, I will still do a blog post on how to create a C module for those that are interested.

What can we build to?

Python runs on nearly every OS and device. However, when it comes to making a game, we are limited to what we can distribute to due to limits of PyInstaller, device specifications, etc. Therefore, our goal with this game will be to have a distributable application available for Windows, MacOS, and Ubuntu Linux.

For any other OS or device someone would want to build to, we will have the source code available.

Leaders in Pygame development / Resources

Pygame has been around since the year 2000, so there are plenty of games and applications written with Pygame that you can look through and follow. However, when it comes to people pushing the limits of Pygame and creating well-written applications, the main two I like to follow would be:

For other resources / documentation, the following may be useful to you:

Forest Defender Devlog 0: Design

Braeden Richards — Wed, 31 Aug 2022 04:12:28 +0000

Shoot 'em up Devlog 0: Design

Written on May 12th, 2022

What goes into Designing a game
Useful tools
Design ideas for this game
Technology and tool choices
Resources / further reading

What goes into designing a game?

Designing a game sounds easy - and it certainly can be at times - but it is actually a long process with many choices to make. These choices can impact development environment, artistic direction, technology used, build goals, etc. The main design choices I find myself making at the beginning of a project are:

What style will this game be in?
- 2D, 2.5D, 3D, VR, etc.
Based on the above answer, what technology will I use?
- Game Engine / Frameworks: Unity, Unreal, Monogame, Pygame, Love, etc.
- Languages (heavily depended on the game engine / framework answer)
  - C#, C++, Python, Lua, etc.
What external tools would be helpful?
- Art tools (Photoshop, Illustrator, GIMP)
- Text Editor (VSCode, VS Studio, PyCharm)
- Etc.
How many people will be working on this project?
What source control system will I be using?

We can then go into the actual game design choices:

Artstyle and color pallete
Theme
Unique attribute to the game
- This would be what separates it from other games
What games can we pull inspiration from?
What is the MVP or Minimal Viable Product
- Essentially what is the minimum needed to get the game ready for demoing / playtesting

Useful tools

As mentioned in the previous section, there are many tools that are useful during game development. Essentially if there is something you'd think "I wish there was a ___ to make development quicker", there probably is! Below are useful tools I have used in the past and can recommend:

Art Tools:

Higher resolution
- Photoshop (paid)
- Affinity (paid)
- Gimp (free)
Pixel Art
- Asperite (paid)
- Pixaki (paid)
- Microsoft Paint (yes, this can be used! Free)

Game Engines / Frameworks:

Unity (free for most)
Godot (free)
Monogame (free)
Pygame (free)
Love2D (Lua) (free)

Source Control:

Git with GitHub or Bitbucket

Task Management:

Trello

Text Editor:

Design ideas for this game

Theme

The game we will be creating will be a Shoot'em Up / Bullet Hell style game. As the player, you will need to avoid the large number of projectiles while attacking and destroying the enemies. Once the level's enemies have been destroyed, the player can move to the next level.

Visual Design

This will be a pixel art styled game. The color palette will be chosen in a later devlog once the basics of the engine has been built. In my past projects it has been difficult to make smooth animation of pixel-based graphics, so a goal of mine for this project is to have smooth and meaningful animation of the environment and entities.

I will also be spending much more time than usual on the graphics and feel of the environment. In the past, most of my time has been on the player and other entities of the game, leaving the environment the player lives in to be lacking in feel.

Goals of project

Smooth / understandable / easy controls
Smooth animations
Minimum FPS of 60 on an average computer
Visually pleasing environment

Story of game

Fungus is a natural and important piece of any healthy ecosystem, but what happens when the fungus becomes sentient and begins to cause damage to the ecosystem for their own gain? As the protector of the forest, your goal is to destroy the villainous fungus and return the land to a balanced and healthy life. You must fight your way through the defenses of the fungus to challenge the Life Mushroom to a battle.

Supported platforms

We will support and build this game on Windows 10 and up, MacOS, and Ubuntu Linux.

Supported devices

This game will be playable with a controller or keyboard / mouse.

Technology and tool choices

So based on my goal for this game and the underlying knowledge I have, I will choose the following from the Useful Tools section:

Art Tools: Pixaki and Asperite
Game Engine and Language: Python with Pygame
Source Control: GitHub
Task Management: Trello
Text Editor: VSCode

Resources / further reading

General:

Art tools:

Game Engines / Frameworks:

Text Editor:

Other

DEV Community: Braeden Richards

Forest Defender Devlog 2: Basic Camera and Movement

Forest Defender Devlog 2: Basic Camera and Movement

Table of Contents

Preface

General Accomplishments

Why movement and camera motion are the most important piece of a game

Movement

Gravity and Collisions

Gravity

Collisions

Other

Camera Enhancements

Finishing Notes

Resources / Further Reading

Forest Defender Devlog 1: Development Setup

Forest Defender Devlog 1: Development Setup

Table of Contents

Preface

What will be used as the development machine?

Development Tool Installation / Updating

Virtual Environment

Installing Libraries

Checking Everything Works!

Resources / Further Reading

Pygame: Can you make an industry-standard game?

Pygame: Can you make an industry-standard game?

What is Pygame?

Let's talk Python

Understanding of basic optimizing

What can we build to?

Leaders in Pygame development / Resources

Forest Defender Devlog 0: Design

Shoot 'em up Devlog 0: Design

Table of Contents

What goes into designing a game?

Useful tools

Design ideas for this game

Theme

Visual Design

Goals of project

Story of game

Supported platforms

Supported devices

Technology and tool choices

Resources / further reading