Introduction to 2D Game Design

Swords and Sworcery

S&S Screen.png

Our first assignment was to create a mockup of a game based on the story of Little Red Riding Hood with an art style similar to a game called Swords and Sworcery.

Swords and Sworcery is a beautiful 2D Point and Click adventure game. The game features stunning pixel art graphics that effectively use a limited colour palette to create a breathtaking environment.

The gameplay in Swords and Sworcery is simple. The player navigates the world by simply tapping on a location on the screen. Pinch controls can be used to zoom in and out, allowing the player to get a better view of the world around them or simply admire the visuals. The combat in the game uses a simple, yet oddly difficult, system to make the player think about how and when they strike their opponent – striking too soon could lead to the player getting damaged and then waiting to  recuperate before attacking again. All combat is done with the device held vertically (this is what triggers “combat mode”.) whereas adventuring is done with the device held landscape.

A simple set of mechanics, paired with a gorgeous set of visuals managed to create an experience that truly captivates the player and allows for them to become immersed in this 2D Point and Click experience.

Our Mockup – Red

Red is the game idea that we created for our first assignment. It is a 2D Point & Click, Puzzle/Horror game.

In Red the player plays the character of Red Riding Hood, a classic fairy-tale character.

The objective of the game is for the player to navigate through a dense forest whilst they are being hunted by the infamous wolf. There are different routes that can be taken through the forest, each can lead to different fates.

It will be up to the player to decide the way that they want to travel, but subtle hints with the level design can give clues as to the direction the player should be heading, or maybe even attempt to steer them off track.

If the player strays too far from the correct path, the wolf will be free to hunt down the player, it will then be up to them to either correct their path, or deal with the consequences.

I believe that the game idea could be improved in some ways. For example with the addition with extra hazards for Red, such as traps in the forest – dynamically placed by the game to deter the player from taking certain paths. This would not only increase the difficulty of the game, but force the player to play it less casually, as they would have to pay more attention to the world around them and look for tiny details in scenes that may cause harm to them in some way.


We had to follow a similar art-style to a game called Swords and Sworcery, developed by SuperBrothers. Swords and Sworcery was originally a mobile game, but was so well received that is was later ported to PC, Mac and Linux.

The art in Swords and Sworcery is very unique, in the sense that it creates a beautiful looking world/environment whilst maintaining a stunning pixel art look that can be awe inspiring at times.ss_b093dc29bf1649dc15761fd4117966fe382196d7-1920x1080

As you can see, SuperBrothers managed to fill the world of Swords and Sworcery with detail despite using only a few colours. This can be seen in this screenshot especially that the core level of the game is designed around only a few similar colours, whereas the background has a smoother, much more realistic look to it.

In my opinion this provides a great contrast between the two layers of the scene and allows for a greater use of art assets overall, as lighting can be much more effective in the backdrop that isn’t using such a limited palette, creating a higher quality image overall.


We attempted to create a similar art-style to that of Swords and Sworcery. To do this we used quite a limited, dark colour palette with clear contrasts between objects and the environment. In this scene we had exactly 32 colours which was quite a challenge to maintain.

As you can see, we created different layers within the foliage, to give the illusion of depth – in a similar way to what Swords and Sworcery did with the colours on their cliff faces and different elevations of bushes. We added contrast between the brightness of the night sky and the foliage layer. to add that extra depth and shading. The moon was illuminating the sky, but that light wasn’t hitting the bush faces that the player was able to see, so it made sense to make those bushes darker than the night sky behind them.

We also used much brighter colours for other elements of the scene, as you can see above – the character, the grave stone and the signpost. This decision was made because it allows these small details to stand out and make them more easily recognisable by the player, so that we can provide an easier game experience overall where the player doesn’t have to stare at the screen to find details, instead we just give them the details that they need.


I also think that this improved the art-style overall, it added a clearer layer of depth and made the screen much easier to read.

We managed to maintain a blocky look at such a high resolution by upscaling. At first, we created an image in Photoshop that was FullHD (1920×1080). We found that there were simply too many pixels in an image of this size to create a pixel art scene, instead the scene looked really un-natural and painted. To solve this, we decided to work with a lower resolution that was in the same ratio as 1920×1080. So we divided both the width and height by 6 and worked from there.

From this we noticed that there simply weren’t enough pixels to add as much detail as the scenes in Swords and Sworcery, so we scaled up – using the Nearest Neighbour setting in Photoshop to preserve our pixelated graphics without forcing the image to try and interpolate between the different pixel colours (this causes a smoother look that looks really weird when working with pixel art). Once we had done this, we simply proceeded to add more detail before finally scaling back up to 1920×1080.

Here is a side-by-side of the art style of swords and sworcery and Red.

I think that we could improve our scene by using more colours. We received comments during the presentation saying that the scene was quite plain, the colours were too similar and this didn’t look as good as it could do. So if I was to recreate this scene, I would think more about the colours that I’m using and make the background much more attractive by adding more bright colours – to rival the darker colours. I think that this could create an interesting effect and we see it quite often in Swords and Sworcery, with the details on their bushes being a bright yellow, on a dark green bush.

Opening Scene


This is the portal into the game for Swords and Sworcery. The object in the middle will fill up by a percentage based on the percentage of the game that you have completed. All that you have to do it touch the object to jump into the game. I really like the idea of this, it’s quite a simple idea yet it’s extremely effective at presenting information to the player.

Once you press this button for the first time, you are welcomed with this scene.

This is the highest resolution image I could find.

As you can see, SuperBrothers used typography to create a medieval feeling. The curly brackets highlight the title in the middle of the screen and make it much more readable.

One thing in particular about this scene that stands out to me is the displayed character. The character seems out of place to the rest of the game, with it having a fantasy/medieval type setting a suited man doesn’t really seem to fit in with the games style. This may be explained later on within the game, but if that’s the case, we don’t know about it – this could lead to player confusion as they are confronted with two possible settings for the game. That’s just my opinion anyway.


When designing our start screen, we tried to follow the similar simplicity of Swords and Sworcery’s opening. This caused it to look quite plain, as you can see above. Of course, we had used up our 32 colours in our main game scene, so a thing for us to work on in the future would be better colour management, as that would have allowed us for a much more detailed opening screen, whilst also having a good looking game scene.

Our opening scene features: Red Riding Hood, the title, the start button and on the right hand side, very faintly you can see The Wolf. We wanted to create the feeling that Red was being watched from the very beginning, so that the player would be more on edge and on the lookout when actually playing the game. This would help us with immersion and make other things like jumpscares much easier, as the player is paying close attention to the game, it is more likely that they will be affected by a loud noise or a sudden sighting with a flash of the wolf – creating a much better gaming experience.

I think that the title scene could have been much better and improved in many ways. For example I would like to change the font to be more typographic, than plain pixel art, as this would allow us to closer match the art style of Swords and Sworcery.

I also think that adding more of an environment, or at least a stage for the characters could have a great effect; the black background doesn’t really appeal to me. I would experiment with a pixelated gradient or maybe even a horizon line, to place the Red Riding Hood on, then make the wolf much bolder and move visible.


Overall I think that our game idea was successful. It was simple enough for novice gamers to pick up and play, yet smart enough to entice even the most veteran player.

If I were to improve upon one thing, it would be the main screen. I feel like we rushed it due to time limits and we could’ve achieved a much greater scene had we spent more time on that than we did tinkering with colours on the game scene.


Assignment 2 – Creating a Unity Scene

Our next task was to create our own scene within the Unity game engine. The scene would have a camera pan that must last at least 10 seconds.

This involved learning about the Unity game engine and then using it’s capabilities to create a nice looking scene.

We used

At first, I wanted to create a swamp-like scene with clear visual depth and detailed parallax backgrounds that would create a very beautiful scene for the viewer. The camera would follow a character as it emerged from under the water and experienced what life was like above the swampy marsh…

This was a little over-ambitious. I didn’t have the art experience to create the Sprites that would portray the swamp in the way that I wanted to, this led to a wasted first few days on the project as I was trying to create something I couldn’t.


I soon moved on from that idea and decided on something much simpler, a plain landscape that followed my original pixie character design.

I designed the rest of my sprites with the SpriteRenderer component in mind. I knew that I could adjust colours and flip my sprites easily within Unity itself so I kept that in mind to easily create modular sprites.

First I created a new ground sprite, this had 3 layers of water (different shades to add the effect of depth) with dirt above that, topped off with grass.

I think that this sprite was well designed because it could be easily flipped in order to create a whole landscape out of just one piece of land. This was great because it helped me finish my scene much faster and it looked good in my opinion. However, doing this also caused seams in between connected sprites – creating weird lighting issues. I would fix this by adjusting the placement of the sprites so that they met exactly at the end of the sprite.

I continued to work in this way for a number of other sprites: background mountains, background bushes and other filler sprites.

This is how the final scene turned out, there are a few problems with this final version that I would improve upon next time that I attempt something like this. For example, there are lighting issues that effect the ground, as well as a few odd animations (the character not flipping when flying in a different direction etc…).

I used several different components when working on this project.

SpriteRenderer – The SpriteRenderer component allowed me to render sprites in my game scene as well as tweak some of the Sprite’s properties. I used this component in order to have differently coloured pixie characters without the need for multiple sprites, saving memory.

Spot Light – I used many spotlights in the scene because my characters emitted light, so I wanted to give that effect by first lighting them and then lighting the area around them. I found that this effect was easiest to do with a SpotLight as there were many properties like range and intensity that allowed me to get my light source exactly how I wanted it to be.

Materials I used materials in order to change the way that light effected my sprites. By default they were using a standard sprite shader. I had to create my own Material that used a Sprite Diffuse shader instead. This allowed the sprites to be effected by lighting so I could create some unique effects to enhance my scene.

Camera – The camera in Unity has different settings that change the way that it works drastically. You can choose between either: Orthographic, so that everything on screen is flat and has no depth (unless you add depth to you art). Or Perspective where you can add depth based on a sprites distance from the camera. I used the Perspective setting in my work so that I could add depth to my scene as well as a natural parallax scroll to the different layers of scenery in the background. This helps make the scene seem a lot better and adds more of a natural feel to it.

Particle Emitter – The Particle Emitter allows you to create Particle Effects to enhance certain things in your scene.  I used a particle emitter on my main Pixie character and each of the tombstones throughout the scene so that they stood out more, I tried to add a “heavenly” sort of effect to them so that it seemed like each tombstone had a story. I think that this would be a nice level selection screen for a game because of how the tombstones are presented.

Programming a 2D Character

We were tasked with animating our first 2D character, you can read more about that on this page.

To make the character respond to user input we had to write some code in a program called MonoDevelop. This program allowed us to write scripts, edit them and quickly recompile for use in our project really easily, making development easier.

I first started by hooking up the animations to work with user input on the keyboard. For this I used the Key’s “A” and “D” (typical left and right controls in a PC game on a QWERTY keyboard.) I checked for this in my Update() function using an if statement that detected when either of the keys was held down and also outputted as false for when no keys were being pressed.

These statements would set a parameter in my Animator to either true/false based on the input, which allowed for my Animator to know which animation needed to be played and when.

I managed to make my character look like they were walking backwards by setting the duplicating the walk animation and setting the speed to -1, this basically played it in reverse.

I hooked that up to play with ‘A’ was held and the regular animation to play when ‘D’ was held. This created a really nice looking flow chart in the Animator.

(insert Animator screenshot here).

The next step up from this was to have the character actually walk as well as animate. I did this the quick way by changing the characters transform position depending on the direction I wanted it to travel. For example if I wanted the character to move left, I subtracted a Vector3 from the player’s current position in the Update function whenever the key ‘A’ was held down, this smoothly moved the player left and played the animation on top of that movement.

I had to make some small changes to how big the vector that I was subtracting was in order to have the amount of movement correspond with the animation, so it looked natural. This involved me making a public float that I could edit within the Unity Editor so that I could fine tune the speed at runtime.

(Insert Side by side screenshot of the code and editor)

Once I had that working I began to add my character jump. I already had my animation so I just had to get it to play on user-input, in my case I used the space bar.

To make the character jump, I used a function in the RigidBody2D component called ‘AddForce()’. This function allowed me to add a force to the character which the RigidBody2D component would then apply other natural forces to the character in order to make it seem real, gravity for example would bring the character back down to the ground at a speed based on both the mass and Gravity Scale of the player’s RigidBody2D component.

My character worked quite well with the base settings so I decided to leave them as they were. However, when programming my characters jump I noticed that to make the player jump to a natural height you needed to apply a force that was in the 10,000’s. To solve this I had another public float called jumpForce and multiplied that number by 1000 when applying the force. This allowed me to keep my editor clean with relatively low numbers, for example I settled on 8.4.

(Insert screenshot of the code)

This was the end of what we was set to do, so I decided to tinker with some things on my own accord to improve my character’s functionality overall.

I noticed that there was a stutter when moving in the air (after jumping) so I added an AirControl boolean that allowed me to set up the character to work in different ways. This helped out when showing what we had done to the class because I had smoother animations at the cost of a feature that nobody really knew was there but me anyway.

(Insert Side by side comparison of jump animations with and without air control)

I think that the stuttering was caused by the way that I added Vector3’s in the Update() function so if I was to go back and improve this I would change my method of movement to be based more on forces rather than adding Vector’s to Vector’s because then everything would be handled by physics so would (theoretically) work better.

Simple Game Mechanics

Next we learned about more components in Unity. These components were Colliders and PhysicsMaterials.

Colliders basically stop anything else that has a collider attached to it from moving past the object that has a collider attached (unless the collider is a trigger).

PhysicsMaterials are components that you can add to a collider in order to change the way that objects react when they collide with that collider. They have two settings, Friction and Bounciness. These can be tweaked to create some really cool effects such as a bouncing ball that uses physics instead of animations.

I created some simple platform graphics and added colliders to them. My rectangular platform could simply use a BoxCollider2D but for my oddly shaped platform I had to use an EdgeCollider2D. This allowed me to shape my collider to the shape of the sprite because Unity can’t automatically create colliders for odd shapes.

(Insert picture of sprites with colliders side by side)

I added a PhysicsMaterial2D to these platforms so that the player had a small bounce when they landed on the platforms or jumped from one to another.

Now that I had my platforms set up, I was free to do what I wanted. I decided to setup a moving platform that the player could jump on to travel to another platform on the other side of the level. First I got the platform to move between two “WayPoints” using simple Vector addition/subtraction and checks to see if the platform’s position was greater than that of the waypoint’s.

Now the platforms moved but the player would have to jump onto the platform and then run in the direction that the platform was moving in, otherwise it would fall off. It fell off eventually anyway because the movement speed of the player was too low to keep up with the platform. I wanted to make this easier.

To fix it, I used the OnCollisionEnter2D() function in order to check if an object or character was on the platform and then if there was I made the object on the platform a child of the platform using transform.SetParent(). This was an efficient way of doing this because we weren’t changing the scale of the character in any way, so there were no issues with the localScale and worldScale being edited separately and morphing our character in a way that we didn’t want.

Now the player moved along with the platform without needing any user input!

Next all we had to do was change the parent to null when the player left the platform and voila!

(Insert platform video here)

2D Game Project

We were given an assignment to create a 2D Game Project to showcase our new animating and programming talents. We were given 4 days to develop our scenes and get them to a standard that would clearly show what we had learned and have them ready to present.

I already had some programming talents and game development experience so within these 4 days I planned to create a functional 2D Game prototype.

My original idea was to have a game show type game, the player would have to drop a ball into a “machine” and try to land it in a basket at the bottom to receive a prize. There would be obstacles that the ball would bounce off of, changing it’s course and making it much harder for the player to know if they would get the ball in a basket and win a prize.

I thought that the game idea was simple enough to get a working prototype done within the time frame that I had, in fact I had a basic version of the game done within the first day.

I opted for the rapid prototype method of development. I used placeholder art to test out the core game concept and see whether the mechanics were fun. I would later replace this art with much better art that suited the gameplay.

At first, the game mechanic was okay, people enjoyed playing the game because of the hope of getting a prize, which wasn’t a bad thing, it’s just not what I wanted. I wanted to create a really satisfying experience where the player would have an intense feeling throughout the course of a turn.

My classmates told me the ball was quite slow, almost like the game was in slow motion. This was the first thing that I tried to fix. I added physics materials to the ball, paddles and walls. Each material was different and effected the ball differently. For example, the paddles applied much more of a force to the ball than the walls would, the ball would always bounce because of the physicsMaterial that it had applied to itself, meaning we wouldn’t end up with dead balls.

I also increased the gravity of the rigidbody component of the ball, so that it fell a lot faster and hit each paddle with more impact. This made the game much more fun to play as suddenly there was impact from the ball and each hit felt much more meaningful.

I then went on to expand the functionality that the game already had, this was through the use of randomly changing levels (I changed the level to another predefined level everytime the player died.) and a mini-map camera that showed a display of the whole “machine”. These features were great additions because I found that it was much more entertaining to watch the ball travel through the whole level from that view than to actually follow the ball. Also, the variation in levels meant that you had to actually think about where you wanted to drop the ball from before dropping it, making it all the more important.

All of the features that I began to add were making the game much more enjoyable to play and of course adding more depth to the game, making it seem bigger and better than it actually was. Here is a list of extra features that I added: Bonus Rounds, Special “Paddles”, Golden/Bonus Balls, Mini-Map, Random Prizes, Random Levels, Sound Effects and idle animations for the player. On top of these features I added some effects to enhance the gameplay and make playing it naturally more enjoyable and immersive. These were: Screen Shake, Particle Effects on collision, Particle Colliders, Sound effects on collision, Moving Baskets and Sprite Switches on collision for the paddles. These “quality of life” or “Aesthetic” effects made the game feel a lot more satisfying to play as each hit and bounce felt like it actually meant something. The screenshake showed that the ball had collided with a strong impact because the screen literally shook because of it. I believe that without these effects, my game would have been rather sub-par and less enjoyable by the players as they found that it had next to no meaning, whereas with all of these aesthetic effects stacked on top I found my game to be of a near professional standard.

If I was to go back and improve this game, I would focus primarily on recreating the majority of the assets that are used. I believe that some of the art was suited to the gameplay, for example the paddles and the balls. However, the environment/machine was lacking in any real art quality, the walls were literally just orange rectangles. I believe that the game would be much nearer a professional standard if I had spent more time on the art in the game, rather on the mechanics and aesthetic things.

Another thing that I would change is the character idea. I was criticised for not properly demonstrating the principles of animation that I had learnt about over course of weeks prior. If I were to add to this game I would do my best to make sure that I could demonstrate these principles not only through character animation, but perhaps through the ball animation (with possible use of squash and stretch on impact). It was my mistake that I hadn’t focused on these aspects of the game, I was too hooked into making a game that I had forgotten what I was actually supposed to be doing and I will be making sure that the tasks set by my tutor are the number one priority in future assignments.

Overall, I think that my final piece was good. I had clearly demonstrated that I knew my way around the Unity Game Engine, as well as my showcase my programming knowledge. To improve I would switch focus and attempt to work more on the art used in my game, coupled with animations to better demonstrate what I had learned thus far in the course.

Here is the final version of the game, I plan to expand on this in the future and potentially release it on the mobile market.

Problem Solving Challenge

We were given some problems to solve using the Unity Game Engine. These problems were:

Make 10 objects that will cause a collectible object to spawn once all are picked up.

Create a treasure chest that opens when the player has a key from elsewhere.

Make an exit that changes the scene once the player has opened a chest.

Trigger a custom character animation when collecting a key.

Create a working title screen.

We had to solve these problems in teams and then feedback to the group at the end of the day to see which problems we had solved. By working together and splitting the workload between us, we easily managed to solve all of the problems given to us.

The main issue that we faced with solving these problems was getting all of our work into one Unity Project. We had some people programming, some working on environment assets and then some on character design. We then had to work to get each of these into one main project and working together. This was time consuming because we went with a simple file transfer method via USB.

I think that this method was okay for the small project that we had, although with a bigger project it would have been wiser to use Source Control services such as GIT.

Morale was good throughout the team as we were solving these problems because everybody always had a task of some sort to be working on, I think that this good task allocation was crucial to us finishing the challenge on time because without it we wouldn’t have had everything that we needed in order to solve the problems in time. Especially the animation ones, as they required an animatable character to actually complete.