Research and Proposal – Exploring Game Art

Before designing my own game art, I first researched the visual elements behind 8-Bit, 16-Bit and 32-Bit games. This enabled me to be aware of the limitations behind these games and decide whether I wanted my game to replicate the style of the 8-Bit, 16-Bit or 32-Bit eras.

 

8-BIT

• Includes consoles like the Nintendo Entertainment System (NES) and the ZX Spectrum
• 8-Bit processors have 256 possible states (places to store information), limiting the types of graphics that could be displayed.
• The Picture Processing Unit (PPU) for the NES output one background layer which is split into 968×8 pixel tiles and a separate layer for sprites. It could only have 256 unique tiles on screen at once so some had to be repeated. Limitations like this resulted in iconic graphics like those in Kirby and Mega-Man.
• The NES could show a maximum of 64 colours, and only 13 at once on the background layer.
• Could choose 4 palettes which are 3 colours each and one backdrop colour. Each block (a group of four tiles) can only use colours from one of the four palettes
• Sprite layer tiles are 8×8 pixels but more than one can be stitched together. Each tile has 3 colours and transparency and can show a maximum of 12 colours on the entire sprite layer.
• Sprites can’t be rotated or scaled and you can only show 64 on screen at once. If you have 8 sprites on the same horizontal line, the rightmost one won’t show up due to scanline limitations

 

Specific Examples:

• The ruby count in ‘The Legend of Zelda’ goes up to 255 because the 8-bit processor only had 256 possible states
• ‘Batman: Return of The Joker’ used animated backgrounds to fake movement
• Mega-Man’s blue helmet and beige face are two separate sprite tiles that make use of transparency. Bosses in ‘Mega-Man 2’ are background tiles instead of sprites

 

16-BIT

• Includes consoles like the Sega Mega Drive and Super Nintendo Entertainment System (SNES) and games like ‘The Legend of Zelda: A Link to The Past’, ‘Yoshi’s Island’ and ‘Sonic the Hedgehog’ 
• Bit Depth – 16-Bit processors contain 65,536 states (2 to the power of 16)
• ‘Mortal Kombat’ and ‘Donkey Kong Country’ were some of the first games to use digitised sprites on consoles, meaning that the sprite graphics were made by converting an external image (e.g. drawings/ photos) into a sprite – this could save a lot of time in the production cycle but photos usually provided less appealing results. Used before processing power and tech prices could make polygonal graphics for home computers/ consoles
• Yoshi’s Island achieved a hand-drawn look by scanning in hand-drawn drawings. When making images for the SNES, artists filled in one pixel at a time to ensure they still looked like the drawing
• Games like ‘Star Fox’ experimented with polygonal graphics

 

32-BIT

• Includes consoles like the Playstation 1 and Sega Saturn
• The PS1 had no z-buffer (depth buffering – management of image depth coordinates in 3D graphics)
• Crash Bandicoot used uncommon 512×240 video mode with lots of shaded but untextured polygons for a sharper cartoon like look that rendered just as fast as lower resolution modes. Also able to use more polygons, so they worked around the PS1’s lack of texture correction and polygon clipping
• Limited the number of polygons you could see (800 for Crash 1, 1300 for Crash 2 and 3) from any given position they could have perfect occlusion and sort, with no runtime cost. The environment is also used to hide a lot of the landscape from view
• Level designs were about 8 to 16 megabytes each, so ‘Naughty Dog’ programmer Andy Gavin developed an algorithmic texture packer that allowed levels to fit into the PS1’s 2 megabytes of RAM. Some levels were 128 megabytes, so a bidirectional 10x compressor was made to help get 128 megabytes levels down into 12
• Used a tool called NPT to figure out how the 500 to 1000 resources that make up a Crash level can be arranged so as to never have more than 1.2 megabytes needed in memory at a time

 

Having completed this initial research, I decided I would attempt to make my graphics look as though they belong to the 16-Bit generation, as this will allow me to include more detail in the art I design.

As I am making my game in the style of a SNES game, I believed it would be beneficial to to further my research into the limitations of the SNES, as these limitations helped create the distinct art style associated with the SNES’ graphics.

In-Depth Study – SNES

• The SNES had over 32,000 colours and was able to simultaneously display 256.
• Resolution can be between 256×224 and 512×448
• Most of the SNES graphics formats use indirect colour – each colour is assigned a number. This format also allows you to switch the palette and create a copy of the graphics with a different colour scheme

• The lowest colour depth that the SNES supports is 2BPP (2 Bits Per Pixel, meaning 2 bits are used to encode each pixel). This means the palette can be four colours instead of 2, and indices run from 0-3. It always treats 0 as transparent. The 2BPP are not stored together in memory.
• The SNES also reads 4BPP which allows for 16 colours, since each pixel uses a 4-bit index.
• 8BPP images allow for 256 colours

SNES Palettes

• The SNES could hold 256 simultaneous colours in its CGRAM at one time. The colours are stores in a 15-bit format
• Palette – the sequence of colours used to colour in a particular graphic according to the colour indices. Palettes can be 4, 16 or 256 colours depending on the bit depth of the graphics themselves.
• The first colour of the palette is always treated as transparent and can’t be changed, even if the tile doesn’t have any transparency
• The first colour in CGRAM, colour 00, is used as the background colour behind everything
• CGRAM holds all of the colours, VRAM holds all the graphics

Backgrounds

• Each individual tile on a background is called a character. Can be 8×8 pixels or 16×16 pixels
• A background can 32 characters or 64 characters in width or height. Background s can have a resolution of  1024×1024
• The data that controls which characters appear on the background and what they look like is called the character data, or tilemap. The tilemap uses 16 bits to name each character in order, left to right, top to bottom. Held in video RAM, the same memory as the graphics data themselves
• Higher priority characters will display on top of other backgrounds and objects

 

Rendering Backgrounds

• Bring in all the available backgrounds and organise them in their true priority order
• Character priorities are set as attributes in the tilemap whilst object priorities are set as attributes in OAM (Object attribute memory)
• A single bit switch can move high priority characters from backgrounds to the very front (useful for HUDs etc.)
• Main screen – always contains the background colour, which is used as the last resort colour when no other layer uses up a pixel
• Colour math – screen addition for glowing effects, subtraction for shadows, and averaging to simulate translucency

 

Game Proposal

• Genre/ Theme: Zombie shoot em up (shmup). Although it is a generic convention for older shmups to use a ship as the playable character, modern shmups like ‘Bleed’ actually use characters
• Artistic Style: 16-bit SNES/ Megadrive graphics – Art is inspired by ‘Zombies Ate My Neighbours’ and ‘Mortal Kombat’. Using 16-bit graphics will enable me to use more colours and hence add more detail than I would be able to if I was creating an 8-Bit game.
• Parameters: Although I am less restricted when making 16-bit graphics compared to 8-bit graphics, it’s important to remember that 16-bit games were still limited in the amount of colours they could use
• Requirements: Have the project completed by the deadline (29th March).

 

Planning – Game Art Planning and Concepts

Firstly, I designed the player’s character. I started this by creating a moodboard of the outfits my character could potentially wear.

Above is the concept art for the player’s character. Although #3 was my favourite design, I didn’t use this concept as I believed the stripy tights would have taken too long to colour each frame when animating as I am not using flat colours. Additionally, if I don’t colour the position of the stripes correctly in each frame of the run cycle, the stripes could move a bit each time and that would result in directing the player’s attention to the character instead of focusing on shooting the enemies, so I went with a less detailed character (#4).

 

Next, I needed to design the enemies. Again, I started by finding images of zombies  in other shows/games:

When designing the enemies, I needed to consider their posture. A problem I ran into was that I was unsure whether to have the zombies reaching their arms out, as this could look too similar to my main character, as she is reaching her arms out with the gun. I wanted to make the zombies have their arms out forwards because this would increase the collision surrounding the enemy, hence meaning there is a greater challenge for the player not to get hit. To ensure the zombies didn’t look too similar to my character, I ensured their backs were slouching (in contrast to my characters straight posture).

Although my final design (#4) is essentially identical to concept #1, I was inspired by my other concepts to make the clothing ripped and have one shoe

Pixel Character/ Animation Process:

Having decided on the final designs for my characters, my next step was to animate them.

Upon opening Photoshop, I set the width and height to the same resolution as the SNES (256×224), the resolution to 72 pixels/inch and set the document from Bicubic Automatic to Nearest Neighbour.

 

Next, I dragged my final concept from its original PS document into my new document (pictured below), achieving the pixel art look. After this, I removed the legs as I prepared to make a run cycle and ‘cleaned up’ the image so it didn’t look like a pixelated sketch.

To create my character’s run cycle, I used the video below as reference in addition to Richard Williams’ ‘Animator’s Survival Kit’

 

Screenshot of the video timeline for my finished animation:

Next, I clicked ‘render video’ and selected the following options:

I then added my PNGs to a spritesheet maker called ‘GlueIT’, which made my PNGs into a spritesheet that I was able to import into Unity

Ideally, I  would have liked to animate the rest of the body such as the arms and the ponytail, but due to timing constraints I was only able to animate the legs for my character.

With regards to making my enemy sprite, the process was essentially the same, with the exception that I used a different reference for the walk cycle of my enemy – this time I used the animation for ‘zombie male animation C’ in the extras of the Resident Evil 2 remake.

 

 

 

As I have another enemy that randomly appears in my game, I saved time by simply changing the hue and saturation of my original zombie in Photoshop. This relates to the fact that SNES games like ‘Zombies Ate My Neighbours’ would often repeat assets and just change the colour of the asset so it looks different

 

Because my enemy can be shot in the game and it is a generic trope for shmups to have explosions, this meant creating an ‘explosion’ for when my zombie is shot using After Effects. To do this, I imported the image sequence of my enemy walk cycle into after effects and added a particle system to it. I then adjusted the values and type of particle system until I achieved a 16-bit look.

After rendering this as a PNG system, I then created a sprite sheet for it before importing it into Unity

Environment Concepts

Having completed my characters, my next step was to design the background for my game. As demonstrated by the moodboard below, I took a lot of inspiration from ‘Dawn of the Dead’ and ‘The Walking Dead’, as well as other zombie games.

 

Pictured above are the concepts for the background to my game whereby I also designed some UI features that I plan to add if there is enough time. I ultimately decided onto use the shopping mall concept as not only did it serve as a nice reference to Romero’s ‘Dawn of the Dead’, it was more appealing than my other concepts and it didn’t look as plain as my other concepts.

Having decided on my final concept, I then needed to recreate the design using a 16-Bit style. As my game is aiming for a SNES style, I found examples of the backgrounds in ‘Zombies Ate my Neighbours’ as well as my main reference image when designing my mall (pictured below)

I found that many assets in ‘Zombies Ate My Neighbours’ were repeated but had different colours so they looked different. This resulted in me taking a somewhat modular approach when designing my background, as I would draw each asset in a separate Photoshop document before adding it to my background and reuse certain assets but changed the hue and saturation to change the colour (I mainly did this on the walls/ shop signs).

Creating the floor

In order to replicate the way some of the floors look in levels of ‘Zombies Ate My Neighbours’,  I found an image of a white marble tile online and added a thin grey border around it. Next, I created a 64×64 (the size of a character on the SNES) document in Photoshop with a resolution of 72. I then adjusted the size of the tile before applying indexed colour and selecting the palette to be ‘Local (selective)’ so I could adjust the number of colours appropriately.

With the tile looking the way I wanted it to, I needed a way to make multiple tiles on the floor for my background.

First, I changed the mode from indexed colour back to RGB so that I was able to go to ‘edit > define pattern’. Next, on the Photoshop document I would be using for my background, selected the paint bucket tool and changed it from ‘foreground’ to ‘pattern’, which allowed me to add multiple tiles in one click.

 

Creating the shutters

Another notable asset was the shutter that appears on the front of some of my shops. To create this, I made a gradient before applying indexed colour and then copied and pasted each row of the shutter this made and made another gradient for the shadow bottom to make the shutter look like it isn’t fully closed.

 

Although I was basing my background on the art style of Zombies Ate my Neighbours, I have created my background using perspective, whereas Zombies Ate my Neighbours didn’t. I made this decision as I believed using perspective made my background look better.

 

Creating sounds

Having imported my background and added the code to my character and the enemies, I then created my sound using Audiosauna, creating a background sound, gun shot and game over sound.

With my sounds exported, I then imported them into Audacity to ensure the background loops well as well as adjusting the bass/treble effects.

Bullet sound example:

 

Creating my UI

As I had some time before the project was due in, this meant I was able to add some UI to my game

Creating my score counter:

To add my scoring mechanic, I created a score script which I applied to my text and used the following code:

Then I added some code to my zombie collision script so that the player would earn 10 points for each enemy they kill:

Additionally, for my score text it was important to retain the pixel aesthetic I had created before. While I had created individual words to use in my game using Photoshop, I would need an actual font for my score counter. To get a pixel font that fit in with the rest of my game’s art, I went to the Unity asset store, where I was able to download the free ‘Thaleah_PixelFont’.

 

Creating my Player Health Bar:

I created my health bar in Photoshop and has 3 different layers to it – a background layer, a layer that not only works as a mask but is shown underneath the current health bar, and the current health bar on top.

I created a script for the current health bar layer, as pictured below:

I then created a damage script which was added to my enemies, allowing them to reduce the health of the player upon collision:

In order to make my player’s health meaningful (i.e. actually do something when the health bar runs out), I called on the scene manager in the update section of my damage script to take the player to the game over screen upon 0 health.

On the game over screen, I give players the option to either restart or quit the game. To do this, I added a restart button my restart text

And added the following script:

for my game over button I again, made a button on my text, but added the following code:

 

Footage of my finished game:

Evaluation

How my game utilised 2D mechanics:

My game features both a health bar and a score counter, which work to enable a sense of loss avoidance. In classic shmups such as ‘Space Invaders’, players would want to avoid dying as their score would be reset to 0 when the game restarted.

Likewise, my game implements both a health bar and score counter (which resets when the player restarts the game) at the bottom of the screen, meaning the player will try not to get hit by the enemies too many times – this too is common of shmups as it is a convention of shmups that the player has to dodge enemy fire or the enemies themselves.

While I am happy with how my health bar turned out given the amount of time I had to make it, I would have liked to make enemies do more damage than they currently do, as retro shmups were often hard as they didn’t provide the player with much health.

However, while the player may have more health than in a typical shmup game, I have limited the amount of times the player can shoot within a given time by adding the following code to my PlayerMovement script:

Although many older shmups are top down as this was a common perspective prior to 3D games, whereas my game is facing head on, which is similar to modern shmups like ‘Bleed’ but also ‘Space Invaders’.

Another thing I liked about ‘Bleed’ was that it used a character instead of a ship, hence me using characters in my game. As it is a convention of the shmup genre for enemies to explode upon being shot by the player, I decided to incorporate this into my game by having the zombies disappear behind an ‘explosion’ of blood.

 

Conclusion

Despite feeling as though my game looks like it could belong on the SNES, I believe I could have considered my colour count a bit more than I did as although I tried to limit my colour count by using techniques such as index colour and repeating colours in Photoshop as this enabled me to achieve the 16-Bit look in the first place. However, I didn’t actually keep track of the precise number of colours I was using and as the SNES can only show up to 256 simultaneous colours, if I was actually making a game for the SNES I would have to keep track of the colour count.

This being said however, I believe I have met my initial proposal as I believe the art I created for this game looks as though it could belong on the SNES thanks to the way I made it in Photoshop (process explained earlier) and I have also managed to implement typical mechanics of shmups into my game, allowing my game to be classed as a shmup.

 

Main references for my research:

WHAT IS 8-BIT?   https://www.youtube.com/watch?v=QaIoW1aL9GE

GRAPHICS IN YOSHI’S ISLAND:  https://kotaku.com/how-yoshi-s-island-got-its-beautiful-hand-drawn-look-1826849563

DIGITISED SPRITES:  https://tvtropes.org/pmwiki/pmwiki.php/Main/DigitizedSprites

16-BIT CONSOLES: https://tvtropes.org/pmwiki/pmwiki.php/UsefulNotes/The16bitEraOfConsoleVideoGames

PS1 GAMES THAT PUSHED THE LIMITS:

http://www.racketboy.com/retro/games-that-pushed-the-limits-of-the-sony-playstation-ps1

SHMUPS:  http://www.racketboy.com/retro/shmups-101-a-beginners-guide-to-2d-shooters

SNES GRAPHICS: https://megacatstudios.com/blogs/press/super-nintendo-graphic-guide

SNES GRAPHICS SERIES:   https://www.youtube.com/watch?v=uRjf8ZP6rs8