Unit 22 & 72 - Platform game development Blog - Concept art for characters, weapons and backgrounds

Short synopsis

Max must set out on a quest through several nature filled environments to recover the diamonds that a giant magpie has stolen. He is an inventor and bug exterminator with a number of different weapons at his disposal.

Max concept design

Concept designs for Max, the main character. I went through a number of designs, taking the character from a humble gardener to more of an adventurer. I felt that the sheer amount of foes and the adventure laying ahead of Max would call for a tougher, more resilient character than his original, softer incarnation (top left).

I can’t say I am entirely happy with Max at this stage. I like the certain elements like his goggles and general demeanor, but feel he could be more iconic. This will be achieved by making certain aspects more exaggerated like his clothes or hair. I will continue his evolution with another design before the final sprite is produced. I also have a clearer idea of the art direction now because of other concept art I have produced for this game since drawing him (i.e, the insects and magpie.)

The sprites in game will likely be PNGs as they will cater for transparent areas around them and be optimized for best performance.

Weapon designs

The bug sprayer design for Max is as follows. It is an upgradeable item with different effects depending on which version you have at that time. From top left and working along each row:

Gas sprayer: Basic weapon, short range. Stuns enemies. Infinite use, does not require a refill.

Chemical shot: Stronger attack, projectile weapon so has longer range.  Stuns enemies. Short use, requires a refill

Smoke machine: For use on bees and wasps.  Stuns enemies. Short use, requires a refill.

Flame thrower: For use on all insects. Destroys insects. Short use, requires a refill.

Bug shot: Extremely powerful rapid fire weapon that shoots small seeds.. Destroys large groups of enemies. Short use, requires a refill.

Bug copter: Means player can travel upwards infinitely without jumping. Drops bombs that destroy enemies. Infinite use.

Weapons will be GIFs or PNGs as they have transparent areas around them - they will be tiny files, around 65 x 65 pixels, and have multiple views of them depending on what the player is doing at the time (for example backpack weapons may be facing in different directions.)

Background designs

Various hand painted backgrounds for each level. They are hand painted to allow the more ‘sketched style’ sprites to ‘pop out’. They will be displayed onscreen as optimized JPEGs to keep the file size to a minimum and still allow for good performance on screen.

Insect enemy designs

Various concept designs for bugs and insect enemies. They represent the foes that Max will face on his journey to recover the stolen diamonds. The finished art style will be very much like the magpie enemy - large black outlines and simple shaded colors to allow them to stand out from the hand painted backgrounds. This will give an ‘animated feature film’ effect, and should produce a very definite art style.

They will be PNGs in game and JPEGS in the cut scenes. JPEGs support a great deal of colors and detail, so will be perfect for storytelling and rich graphics between levels.

Magpie concept design

A full size drawing of the main villain in the game, a magpie. She is queen of her treetop domain, crafty and a thief, hence her expression and personality. This heavy black line style drawing style will help the sprite to stand out from the backgrounds (see diagram in the top right hand corner). The solid, cel - shaded artwork style will also lend itself to ‘pin-puppet’ type effect when it comes to animation. For example, the wing can be cut out and over laid over the bird’s body with a single joining point where rotations can occur. This will lead to the effect of the wing flapping smoothly. The same effect could be applied to the head, tail and beak. The animation is essentially 2D with parts being animated to fool the eye into thinking it is more 3D than what it actually is.

The sprites in game will likely be PNGs as they will cater for transparent areas around them.

Unit 22 & 72 - Platform game development Blog - Diamond collection design

I am still working with the test level and the place holder sprites and objects I have created. 


I have programmed the game to have some kind of block to the exit that is only removed after the player collects all the diamonds on the level. In short the code is set to recognize that when all the instances of blue diamonds = 0, the block will disappear when it is touched. The pictures below illustrate the process of this:

The player must collect all the blue diamonds. The black block with the 'X' represents a block that will disappear after all the diamonds are collected.

If the player collides with the block when there are diamonds left to collect, the block will not disappear.

When all the diamonds are collected, the instances of them will be set to 0. The block will then disappear when the player collides with it.

Unit 22 & 72 - Overcoming problems during development

I have decided to tackle the side of things I am less comfortable with first - namely the logic of Game Maker and it's interface. I have built some dummy sprites, objects, and a room:

Test sprites to help me to get to grips with Game Makers' gravity. I know can substitute these for the real game sprites later on. At the moment, understanding gravity is key.

First problem: friction between player and platforms

One of the first problems I have encountered during the development of my platform game concerns my main sprite 'sticking' to platforms. Why this is, I am not sure. I tried altering bounding boxes around the sprites. making them more precise in the hope that this could solve the problem. So far, nothing. I can only move left and right when I jump in the air. This implies that the problem is in the relationship between sprites and platforms:

My sprite 'sticking' to platforms and being unable to move

My sprite can jump fine, and even move left and right in the air.

Solving the problem - 3/12/14


Eventually, using this short script, I semi solved the problem of gravity and friction. The first step was to create several variables: gravity, horizontal speed, vertical speed, jump speed, and move speed 

In player object : CREATE EVENT

//Variables
grav = 0.2;
//Horizontal variable
hsp = 0;
//Vertical variable
vsp = 0;

//How fast to jump and move
jumpspeed = 8;
movespeed = 4;

The next step was to create a short script that first checks if certain keys have been pressed: Escape to exit game, left, right or up to jump. Following this, the code checks to see if left and right are pushed together. If so, the movement cancels out and does nothing. This is checked by left and  right both equaling 1. move will equal 1. If both keys are pushed at the same time move will equal 2 (1 + 1) and the movement cancels out.

Next, the horizontal move speed (hsp) is calculated. This is worked out by first checking to see if left or right has been pressed . hsp is initially set at 0. If left or right has been pressed it sets to 1.

hsp then has a new value applied to it using move (1 due to the playing pushing left or right) * movespeed (4). So, 1 * 4 = 4. hsp is now set to 4.

Next gravity is worked out. grav is already set to 0.2. Every time the player pushes up to jump, 0.2 will be added until it reaches a maximum of 10. After this the player will fall back to the ground. The code for this is worked out via a kind of loop - what the code is saying is:

"As long as the vertical speed is less than 10, take vsp (0.2) and add 0.2 every time up is pushed until it reaches a maximum total of 10. After this a gravity of 10 will cause the player to fall back to the ground."

If the player is already on the ground and jump has not been pressed, vsp = 0. Once up is pushed (so 1 is set) vsp is assigned a new value - 1 * -8.

Code inserted into player object: 

In player object : STEP EVENT

// End game

if keyboard_check(vk_escape){game_end()}
//////////////////////////////////////////////

// checks to see if key has been pushed

// this does not move player

//if pushed key_right = 1
key_right = keyboard_check(vk_right);

//if pushed key_left = 1
key_left =- keyboard_check(vk_left);

//if pushed key_jump = 1
key_jump = keyboard_check_pressed(vk_up);

//move is a temp variable 
// move = 1 for left or 1 for right
//if move =  2 cancels out movement  if left and right are pushed
move = key_left + key_right;

//hsp = if key_right or key_left has been pushed hsp =1

//move already = 1 from left or right  pushed
//1 = 1 * 4  up speed
hsp = move * movespeed;

//if you have pushed up gravity "0.2" will be added until to vsp =10
// then the play will drop
if (vsp <10){vsp += grav;}

//if your player is already on the ground vsp = 0 until up is pushed
if (place_meeting(x,y,obj_blk_4))
{
    // 1 = 1 + - 8 down speed
    vsp = key_jump * - jumpspeed
}

// co-ordinates of player on the screen
x += hsp;
y +=vsp;

The resulting problem of using this script was yes, the player moved, yes the player jumped, but unfortunately there was a 'sticking' issue when the top of the player hit the bottom of blocks. This was unacceptable to me, and looking at the code I felt sure that there must be a more streamlined solution.

The issue is finally solved - 9/12/14

I worked towards and eventually achieved the solution by writing this code and inserting it into the player object:

Comment: // initialise variables

grav = 0.2;   // (gravity)

hsp = 0; // (horizontal speed - set to empty because initially, it is just a container)

vsp = 0; // (vertical speed - set to empty because initially, it is just a container)

jumpspeed = 7; // (the amount of speed that will be added to the object in the up direction when we jump)

movespeed = 4; // (the amount of pixels that we move left and right when we press those keys)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Add Event

Step (This means that these events carried out by the object will happen every single frame of the game)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Drag in code box into actions panel

Add comment // get the player's input

Check player movement inputs - this is done by assigning the results of keyboard checks to variables.

Type this into the code box:

key_right = keyboard_check(vk_right);

// if key is pressed, this variable will equal 1, otherwise it will equal 0

key_left = -keyboard_check(vk_left);

// minus before keyboard check - this mens it will equal 0 or -1

key_jump = keyboard_check_pressed(vk_space);

// pressed means the computer checks to see if the button was pressed, but it

// was not pressed the frame before - i.e, literally just pressed jump button.

// Means you can't just hold the jump key down to continually jump

// React to inputs

move = key_left + key_right;

// -1 if left key is pressed, 1 if right key is pressed and 0 if neither is pressed

// If both are pressed it still equals 0

hsp = move * movespeed;

// As move (shown above )equals -1 or 1 and move speed = 4, this should set hsp in this instance to either - 4 or 4

if (vsp < 10) vsp += grav;

// vsp will add 0.2 to itself, up to a maximum of 10. This controls the falling rate

// of the player, otherwise the onscreen sprite would just pick up speed with every frame it falls
// with no limit

if (place_meeting(x,y+1,obj_wall))

// This is asking "Is there an object called wall 1 pixel below the player"?

{

    vsp = key_jump * -jumpspeed;

    // If jump key is pressed, this should set the jumpspeed to -7. If not, 0.

}

// Collision - Ordinarily in GM if you've collided with something, it's already too late

// What you need to do is get into the midst and logic of saying to the computer we are "ABOUT"

// to collide, do something NOW

// For example, our hsp here = 4. If we are three pixels from a wall, we need to ask the computer

// are we about to hit a wall to our right?

// If we are 3 pixels away, we move 1 pixel at a time until we can't move any further without hitting

// the wall and we reduce our speed to 0

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

// Horizontal collision

if (place_meeting(x+hsp,y,obj_wall))

{

    while (!place_meeting(x+sign(hsp),y,obj_wall))

   // sign will return 1 or -1 depending on whether hsp is positive or negative
   // so this would equate to x left or x right (-1 left or 1 right)
   // sign will multiply this by the horizontal speed -1 * 4 or 1 * 4. This gives the current amount of
   // pixels to move left or right for the horizontal speed.
  // So what you are saying is, if the player is not touching obj_wall, keep on moving 1 pixel
  // until it does. At which point reduce speed to 0 and stop. Same principle goes for vsp below.  

    {

        x += sign(hsp);

    }

    hsp = 0;

}

x += hsp;

// add horizontal speed to x co ordinate - move sprite left or right

// Vertical collision

if (place_meeting(x,y+vsp,obj_wall))

{

    while (!place_meeting(x,y+sign(vsp),obj_wall))

    // sign will return 1 or -1 depending on whether hsp is positive or negative

    {

        y += sign(vsp);

    }

    vsp = 0;

}

y += vsp;

// add vertical speed to y co ordinate - move sprite up and down

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

This code works perfectly and solves the problem - pixel perfect gravity. I went on to apply this code to every surface in the game to create a solid, interactive world.

 



More problems to write about in future blogs -
Sprite collision with walls and blocks (show code mistake and explain why)
Sprite resizing
Platforms and destructible. Switching from one state to another - the way I solved the problem.
Platform generator and its problem - sticking and turning a positive into a negative

Choosing the right power ups
Choosing and designing the games enemies

Creating Joe-bot and his reason to be in the game.

Fine tuning.



Unit 22 & 72 - maze game development blog - Designing the maths puzzles and how they will be delivered

I already know that as part of the gameplay for this game, Brainbox will have to light a dragon lantern on each level to awaken the statue. This in turn will ask a sequence of questions based on addition, subtraction, division or multiplication. Answering these correctly will unlock the exit to the level. The advantage of this is that the puzzles can be very visual since they appear as on screen illustrations.

The dragon lantern concept process is below, along with the final character design:

As you can see, I did a number of character sketches that I then combined the most interesting bits of to make the final character.

Unit 22 & 72 - Platform game development Blog - Game play and level design.

Unit 22 & 72 - BTEC Level 3 Games Design

Platform game

Max has to go on some kind of a journey. This much is clear to me even at this stage. What I am planning is for him to traverse through several levels that represent different environments. What I would like is to make level environments that are interesting, imaginative and surprising but make sense in the game world. So what I am thinking about is this:

Level 1: Ground village and tree roots - beginning the ascent - Armored bug boss

Level 2: Honey comb mine - bees at work. Queen bee boss.

Level 3: Outside the tree trunk - lost colony - Squirrel boss

Level 4: Inside the tree trunk - a climb upwards through the dark - Scorpion boss

Level 5: Spider kingdom - Spider king boss

Level 6: Crow's kingdom and crow's nest - Crow boss

It would be good to inject an element of humour into the enemies. In fact the whole game should be built to entertain, I do not want it to be making any big, serious statement, just a fun game with interesting construction, gameplay and playability.

I like anything steampunk, so I may be daring and inject an element of that into it - clockwork insects or armored bosses.

I also like the idea of human characters scattered throughout the game to sell items, give hints or unlock new areas. Having small people in an oversized world would definitely help the fantasy adventure ideas come across more strongly.


Plot developments
Additionally, I have been thinking about the games story and how it will fit in with the parameters set out by the brief. Max must collect diamonds to progress. The original villain for the game was a giant crow. It has occurred to me that a giant Magpie would be better. The Magpie has stolen the diamonds and left them scattered throughout the levels. Perhaps Max could be attempting to recover stolen diamonds for his people. The Magpie could have stolen something within the town such as the town's clock (a giant pocket watch). This would make more sense in terms of the plot's parameters.


 

Unit 22 & 72 - Platform game development Blog - Brief

Unit 22 & 72 - BTEC Level 3 Games Design

Platform game

What does the customer want?

A platform game featuring a character called 'Max'. The main character of this game ‘Max’ has to move from level to level solving fighting (and/or dodging) monsters which either chase Max or block his way. Max progresses from level to level collecting weapons to fight the monster and/or avoiding the monsters.

Max gets score from collecting diamonds and from killing monsters. He has to collect certain items to unlock doors to progress to the next level. This is a platform game so I would expect Max to be able to jump over obstacles / monsters.

What does the design brief say?

The design brief specifies that there must be a main character, collectibles, puzzles and and enemies. There must be at least five levels that will eventually culminate in a boss fight. There must be a minimum of 5 levels for Max to explore.

The game play must be built around collecting diamonds and killing monsters. As a platform game there must be a mechanic in the game play to kill or avoid monsters.

Max has to collect certain items to unlock doors to progress through the game. This could be in the form of keys or any other form - this could be by completing mini side quests for non player characters. This might work well as introducing narrative into the game. 

There must be some kind of score mechanic. Perhaps this could be linked to unlocking new areas.

In terms of weapons there must be some kind of upgradable weapon system - this could fall under the mentioned collectibles that the player must find - tougher enemies may not be able to be bypassed until the correct weapons are found.   

Who is the target audience?

The target audience is the 7 - 14 age range. It could also feature game play that would appeal to families. The game play must be simple enough for young children to adapt to it, but intriguing enough for older players to discover hidden secrets. Families should be able to comfortably play it with their children.

It would also be interesting to make something that females would want to play. A challenge would be to make an action game that appeals and is challenging, but is not patronizing.  

I am also still very interested in making something that plays like a retro coin op arcade machine to appeal to nostalgic players. These players are likely to be the ones with families buying it for their children. Retro games are very popular, even today. It would be good to make something that kind of spirit, but freshen and update the gameplay with some new features and ideas.

What sprites do we need?

As a minimum, we will need:

- A hero, 'Max'
- Various enemies
- Several background designs
- Textures for the platforms
- Diamonds
- Keys or items that will unlock the next level
- Non player characters to help and guide the player
- A boss monster
- Weapons and weapon upgrades

What sounds do we need?

As a minimum, we will need:

- Music
- Character sound effects
- Monster sound effects
- Weapon sound effects
- Collectible and incidental sound effects

How many levels do we want?

A minimum of 5.

What other elements do we want?

Ideally it would be advantageous to have:

- A start screen
- A how to play screen
- An ending screen 

What do we want to do by the end of this session?

24 / 11 / 2014 - To have written this plan and completed the game play design brief
25 / 11 / 2014 - To plan and design the look of the character of Max.

How long do we have to create the game?

We have approximately four weeks to create this game.

How can we break down the tasks in making the game?

The tasks can be broken down as follows:
1) Design game play
2) Design sprites
3) Bring sprites into Game Maker
4) Make objects and platforms in Game Maker that interact with one another and create something that can be played
5) Implement physics for player, platforms and weapons
6) Implement score and collectibles
6) Implement a way to progress from level to level
7) Implement health and lives
8) Fine tune game play
9) Add in start screen
10) Add in end screen

Gameplay outline

A fun, bright sparky cartoon adventure in the spirit of old retro arcade coin op games. The game is set on a planet that is populated by trees that are miles and miles high. Everything is big and over sized. The tree tops are largely an unexplored area and are home to many races, cultures and creatures. Many of these have rarely been seen by men. On the ground, a gardener and his son Max, tend the plants and trees. It is their job to water the roots and flowers and maintain the plants and wildlife.

One day a large crow that rules the tree top kingdom swoops down and kidnaps the gardener, taking him back to her kingdom. It is up to Max to rescue him as he begins the ascent to the crow’s kingdom. Along the way he encounters friends and enemies, collecting power ups and discovering the truth about his father’s disappearance. The aim of the game is to travel through several vertically scrolling worlds until the two gardeners can be reunited.

The game will feature large, chunky sprites, imaginative backgrounds, fun power ups and a catchy soundtrack. It will be deliberately simple and not overtly violent. The game will instead focus on a cartoon, knockabout style of action like Mario or Zelda. Not to say it won’t be challenging at times – there will be levels and obstacles that will heavily test the players reactions.

The power ups will vary from simple gardening equipment through to spells and artifacts and inventions of ancient cultures later in the game. In fact each world will have its own specific objectives, obstacles and available power ups.

Here are some initial sketches of my game - my first thought for the hero Max, and a quick thumbnail sketch of a level layout :

Max is a little boy who carries a large can of bug spray on his back. His enemies are all oversized insects and creatures found within nature. The bug sprayer effects can be altered by attaching different units on the top of it. The effects could be as follows:

- A standard bug sprayer to ward off enemies

- A freeze sprayer to stop them momentarily ;cools them down to freezing temperatures

- A fire sprayer to scorch them

- A seed sprayer that acts as a ranged weapon

- A reverse sprayer that sucks up enemies like a vacuum cleaner

- An air sprayer that blows away enemies and enables a boost jump.

You can see that the Max also wears a hat. He could collect different hats that grant different effects: for example, a propeller hat that enables flight.

This is a small section of a level. You can already see there are plans for enemies, platforms, ladders and explorable areas of the map. These will create depth to the levels, hidden areas and secrets to find. Hopefully this will begin to create a depth to the game play that is more interesting than just going from A - B and stop the game being repetitive. I want there to be a reason that the player has to explore. Exploration and game progression should go hand in hand.

You can see more detailed mock ups of the levels in the next blog.

P2 recap

BTEC Extended Diploma in Games Design

Unit 78 Exercise : Computer game graphics

Pixel art :
Resolution
Compression
File extensions
Image capture
Optimizing
Storage Of Image Assets

3D Art:
Vectors
3D polygons
Rendered cut scenes and animations

Heads Up Display

Background graphics
 
Logos, graphic design and typography
 
Packaging
 
Advertising - eg: Posters, Adverts, Point Of Sale, TV adverts, Viral videos, social media
 
Concept art - drawings, photographs, mood board, videos
 
Artistic Styles - e.g: Photorealism, Abstract, Cartoon, Cel Shaded, Anime
 
Texture art

---

Unit 78 Exercise : Computer graphics specification
 

 

The dictionary definition of the word "specification" :

 

an act of identifying something precisely or of stating a precise requirement:

"give a full specification of the job advertised"

 

a detailed description of the design and materials used to make something.

"one of the telescope's mirrors had been manufactured to incorrect specifications"

 

 

 

In terms of computer graphics, the term specification could refer to the individual components of what the graphics are made up from. The individual components could cover areas such as:

• Resolution
  - This refers to the how sharp graphics appear on screen

• Compression
  - This refers to how files are shrunk down to reduce their size, and how much this affects image quality

• File extensions
  - Naming conventions that the computer uses to identify types of files

• Image capture
  - Ways of bringing an image into a digital computer environment

• Optimizing
  - Ways of allowing a system or its graphics to run at their very best performance

• Storage Of Image Assets
  - Ways that data and graphics are saved securely within a computer environment

 

These requirements are directly related to the platform, application or operating systems that is displaying the graphics. For example a higher spec machine may be able to handle a greater resolution than a lower spec machine. For example, a PS4 will have a different set of specifications to a 3DS - there will be acute differences in the graphics, resolution, file types, storage of assets and compression.

A specification could also refer to a client brief - they will specify certain parameters for the project from the outset. For example, they might say that they want a 3D fantasy adventure to run on the 3DS. The artistic style should be cel-shaded and be bright, fun and appealing. The client may say that they want a mixture of 3D sprites and 2D backgrounds.

Specification can also include typography - a certain sort of font, look of the graphics' text or design of the games' logo. If the game already has an established brand, the client could opt to specify the inclusion or updating of any existing logos or typography.