Introduction

For a year and a half, when I have time, I'm learning the ways of pixel art. One of the reasons for it was the fact that I always hoped to make my pet project - Jessie KA 2 (and eventual sequels) with new art, replacing RPG maker art.

While learning I was making art for a platformer, a very restricted art with a small color palette and main character height of just 16 pixels.

I decided to test it, both character and tileset, using the newest LTS Unity version. I figured it would be a good idea to learn what features Unity has regarding platformer type of games. Before that I was just making 3D games in Unity, and in older versions.

And so it has begun... from a simple test to a demo for a game...

I have spent most of the time coding and working in Unity rather than making art, but I've learned a lot and hopefully now have a much better understanding of how Unity works, especially since I've never done 2D game using it, and there are plenty of specific situations while making a 2D game.

Project setup

As in the beginning I "just" tried to make tiles and characters to work in Unity as a test, I obviously missed an important step you usually (should) do when making a game - I didn't have GDD or any production plan.

I just wanted for the character to move and jump across my tiles!

But during this process I learned about new and (at least for me) cool features Unity has. So I decided to build my game around it. Also I decided not to use any 3^rd party plugins in the hope that I will better understand how things work if I do most of it just with the tools Unity already has.

In this short time I've made a general idea of what I want to do with the demo level - SPoM should be an old school platformer with simple jump, run and attack mechanics. There will be two types of enemies - patrolling and stationary. Gameplay will be based upon learning how to cross the level by repetition - very old school - but to make it less frustrating there will be a checkpoint system for a player to respawn after being killed so the player can get back to the obstacle quicker and try to beat it in the next try.

To make the demo level, apart from coding, there should be much more art than I had at the time. I made a list of all the elements I needed and started working.

Example when you start a project as a quick test: Player animation - just "quick testing" (RED) vs "after a little planning" (BLUE). What's actually quicker and smarter?

Graphics

Game level art:

Apart from character and basic tileset art I already had, I needed more details to the level.

Main game level now consists of 9 layers of tiles: 4 terrain tiles, background, sky, sea, clouds and animated details.

Tileset objects - plus moons art

Some of these are very simple but I've divided them into different tile grids so they can be rendered in front or behind the player character.

Some of the tiles are animated (sea), while some are moved by a script (clouds, background)

Script for animation of layers

There are three types of enemies, two are visually the same except for color, and there is one new character - a princess. Because what kind of a game Saving princess of Mars would be without a princess?

Other elements on a level are checkpoints, jail, key, animated effects, etc.

Character art:

I've made a complication by doing special sprites and animations for all characters depending if they are turned to the left or to the right.

This will cause future art to be made slower, but I think the game looks better for it.

Different sprites and animations for characters facing left or right

UI art:

Although technically not an UI there was a background image for the main game screen that needed to be done. I've animated it a little to make it more dynamic. I've also made an animated game logo.

Game UI elements consist of panels, buttons, cursor and game UI - in this case health and attack bar.

Gameplay mechanics

Here we get to the hairy stuff...

Player movement:

Although at first simple platformer movement mechanics it proved to be rather tricky! I'm still not 100% happy with it but it works as expected... sort of.

Physics has a mind of its own and I had a lot of issues forcing it to work as I wanted. I'm still tweaking it and hopefully I'll get it done for this first level in this demo version and won't change it after that - for next levels.

Main issue was to make different player states (jump, run, etc.) to work in synchronicity with collisions and animations. The Animation system too has its own "timeframe" and I had a hard time figuring why something won't work as expected.

Main issue - physics works on its own time frame, scripting on its own and animations on its own. My solution was to make all animations loopable, even if they are played only once.  This avoids the player being stuck in one animation although player state has changed in code - depending on collisions or player input. The other solution was to avoid changing state in a script when in fact it was connected with collision state. For example if a player jumps and changes state to jump, physics is still touching the terrain bounding box and state JUMP gets negated in the next update.

Another issue was regarding player characters sliding over tiles and falling off the edges way too easy. For this I did a lot of tweaks regarding both player and tile composite collision box. Depending on the testing reports I’ll change this further.

For terrain detection during jump/fall state I’ve added another collision box under the player character designed to check if terrain is indeed underneath the player. This bounding box is narrower than the main player collision box to avoid detecting vertical terrain tiles, since I don’t want the player to jump off vertical edges.

Collision box underneath the player character for detecting terrain (here sprite renderer is enabled so it is visible as red object)

Player attack:

Attack is completed by falling on the enemy or by hitting it using a special attack animation. To avoid button mashing for the latter I've introduced attack cooldown. Enemy is hit only while this animation is played, and hit is successful only once per hit animation of that enemy. This avoided enemies being killed too quickly.

Implementation of attack cooldown gives an opportunity for powerups and player character upgrades later in the game.

Player's Attack (cooldown) and Health bars

Enemies - movable:

Movable enemies patrol the area between two points. To make the setup easier I've made a prefab that consists of an enemy prefab, two boundary objects and a trigger. Trigger is auto scaled based on the boundary objects and is used to detect the player and puts an enemy into attack mode. During attack mode the enemy is quicker, goes toward the player and uses attack animation. Enemies also have an attack cool down and they deal damage to the player only during attack animation.

EnemyA_Set prefab (EnemyB_Set is the the same except for EnemyB prefab - different sprite and characteristics)

Enemies - trap:

This type of an enemy is in fact area traps and cannot be defeated. Player needs to learn to detect them and avoid them as they deal maximum damage.

Tiles – terrain, sea:

Terrain tiles are the main areas of the game level. I went for the simple tile level design where the player can walk only on horizontal tiles, while vertical tiles are in fact obstructions.

Sea tiles are also meant as obstructions and players should avoid falling into them. Although if quick enough and if there is a terrain tile close underneath the sea surface, the player can jump out! I decided to let this be... so it’s a feature, not a bug!

Checkpoint and save systems

Checkpoint system is straightforward enough – once a player character reaches a checkpoint it becomes an active checkpoint and the player will respawn there if is killed before reaching the next checkpoint.

When a player decides to continue playing the game from the main menu, the game will continue from the last checkpoint reached. For this to work I’ve made a checkpoint control system which goes through all the checkpoints until and including the last one reached and activates/deactivates objects connected to each of the checkpoints checked. In this way Save file needs to remember just the last checkpoint reached, and also makes on level gameplay logic easier to follow player's progress.

Checkpoint controller scripts - important for controlling game progress and communicating with checkpoints

Dialogue and cutscene logic

When I started working on this project as a game demo I figured I needed a dialogue system but the idea of some kind of a control while playing those dialogue - a cutscene system - came after and I’m not proud of the fact that I didn’t plan it from the beginning.

Script which controls all the elements needed for cutscenes. Cutscenes can be disabled for debugging purposes.

It was tricky to implement it “quickly” after character and object movement was already done. There was a lot of figuring out what to do and how to do it...

This system works ok now and I made it so it can be (hopefully) easily rewritten. Most of it I want to put outside of the code and use csv tables for both dialogues and cutscenes - in fact they are separated because sometimes dialogues can be played while gameplay is active.

Cutscenes and Comment trigger objects handled by Cutscene Controller for the first game level

Rewriting this system will make implementation of dialogues and cutscenes much easier. Now setting up dialogues and cutscenes is a tedious process.

Logic of this system should be connected with the localization system I’m still missing and is something I plan to do in future instances of the game.

SPoM plans

After the release of the demo with the first game level, and all the updates the demo will receive (depending on the reports) I’ll continue making levels for the game. My goal is to make (at least) 6 more levels and finish the game story. This should be done until the end of the year.

In the new levels I plan gradually to introduce new gameplay mechanics thru new playable characters and new level design obstacle mechanics. Our main character will still be used on each level but the player will be able to switch between him and other characters on the level to access and use new abilities this new character possesses.

Big deal of work to do will be localization and rewriting some of the code (dialogue/cutscene control).  Implementing localization doesn’t necessarily mean there will be multiple language support in the game, but logic for this will be there and I want to make all strings to be outside the code. That’s something I didn’t have time to do while finishing the demo as it would delay release for too long.

And my older code for it was done for Unity 2017 and doesn't work in the new version.

But before all this I need to finally sit down and put it all on paper –making a GDD and defining precise goals for the production of this project.

Unity preview packages used:

2D Tilemap Extras - Version 1.8.1-preview

Links:

I learned a lot by attending this pixel art course and I highly recommend it:

https://www.udemy.com/course/pixel-art-master-course/