The first step was getting to know PyCharm and setting up a project. As I had never worked with Python before getting a square on the screen that can be moved by Keyboard input was already a challenge. But the reward was great.

As the square was finally able to move, now it was time to implement collisions. But with what should the game collide? The ClearCode tutorial suggested an integration with the software Tiled Map Manager, that lets you create tilemaps, using pytmx. I wanted to learn and not copy the tutorial, so I immediately started creating my own files, writing my own code always a bit different were it made sense. After all I wanted to learn from the tutorial, I did not want to recreate the same thing. The collisions then were modular for every tile. At the bottom of my movable square another rectangle was drawn, checking contact with the ground. Additionally two rectangles for the sides, to check contact with walls. Gravity was a simple function applying a constant value to the Y-position of the initial square when no collisions were checked.

Pytmx could load surfaces from tiled. So I was able to replace the white rectangles with a tileset, that can be imported into tiled. This modular setup would already be enough for the entire drawing logic for the surroundings. Any image I wanted could be imported into tiled and used via the .tmx file. With Z-Layers I could also control the drawing logics order. That way I could have tiles infront of or behind the player which allowed for more depth.

For the animations the import of more assets was needed. For that I used import functions, the same as ClearCode, from StackOverflow. The animations of my protagonist, the Chicken, I made myself in Aseprite. With the import functions I got a dictionary in Python called ‘level_frames’ with that I could load assets modularly. An object created in tiled was loaded in Python and for every objects name there was a path in the dictionary, containing all frames of its animation. These were played using Delta-Time, a time indicator that is not dependant on the framerate.

Depending on Inputs or several other functions the player object gets assigned a different state. The animation of the player is always from the folder containing the states name. So when I coded the block function, when ‘B’ is pressed the player-state gets changed to ‘block’, thus the ‘player_frames’ (a part of ‘level_frames’ containing all player animations in subfolders) uses the appropriate folder: ‘player_frames[state]’.

Everything in the game is part of Sprite Groups, a concept that is made easy to use with Pygame. If an object is part of the group ‘damage_sprites’ and a collision with the player is detected, the players health will increase. Otherwise the Enemies are objects the same as the player, some have different states, resulting in different animations. Each enemy had it’s own difficulties to be programmed. Items were easier: when a collison with an object of ‘item_sprites’ is detected, the player data changes (health or coins increase/decrease).

A lot of things were small parts, that need their own time to program. Each of the previous steps can be divided into several steps, because I am greatly simplifying here. Each step takes days. Other methods that needed to be done were a goal collision, so there was a winning condition, a death and respawn method, a method so the player would respawn, a method for the drawing of the paralax background and many methods for enemies or player movements. Coding the menu and the start screen was something I did by myself. 

The most time consuming part was debugging. Some things don’t work like you want them to, sometimes not at all. Finding all these little things and fixing them takes enormous amounts of time. Sometimes the result is not even clearly visible, but fixing it took 5 hours.

The exporting of the game so that it can run in the web was a very complicated process, due to optimization and debugging problems. I had some library erros when trying to convert from Python to WebAssembly using Pygbag, where I thankfully could connect with the creator of Pygbag to resolve this issue. But after that some culling methods and image conversions were needed so that it runs semi-smoothly.

The game still needs a lot of updates. A controls screen, better levels, multiple levels, different settings, UI, progress saves and better controls and sound effects are needed. Stay tuned for version 1.1!