Showing posts with label Maze Game. Show all posts
Showing posts with label Maze Game. Show all posts

Monday, 8 December 2014

Maze game Progress Week 1

Maze game in GameMaker
Level 3 Diploma in Video Games Design
Client Brief
Create a maze game for the students to play that also helps them develop their mathematical skills
The main character of this game “Brainbox” has to move from level to level solving increasing difficult maths based problems. Each level should show a different maths problem and the level of the maths problem should be GCSE grade C Mathematics. It must have at least 5 levels of increasing difficulty with collectables, enemies.
Target Audience – The target audience is people who are aiming to improve their maths skills to GCSE grade C level. This would most likely be GCSE students studying for their GCSE’s who are around the age of 15 and 16.
Aim of Project – The idea is to create a game that is both enjoyable and helps people learn better maths skills. I will aim to do this by combining fun gameplay with maths based puzzles. I have created a setting of a futuristic school where the teachers are cyborgs and have malfunctioned. The player will play as Brainbox, a similar cyborg, who must defeat the teachers and improve their maths skills along the way.
Own Brief
I am aiming to make a maze game that will teach GCSE grade C maths to people playing the game. The target audience will be mainly students of age 15 and 16 so I will have to make the game exciting and engaging to someone of that age. I will also have to be aware of creating content that will not be suitable for people of that age. This is something that I would learn through Pan European Game Information or Entertainment Standards Ratings Board. These bodies govern over the age ratings that games are given which warn people of the content and make it illegal for people under the appropriate age to buy the game. I will aim to make at least 5 levels of increasing difficulty. This will be both in maths and maze difficulty. It will include a “time limit” mechanic whereas the player plays through a level there will be a countdown clock that when it reaches zero the player will have to start the level over. This ties in to the idea that the player has to quickly make their way to a ticking time bomb that they will have to defuse with a maths problem. It will feature obstacles such as electrical discharge that bounces around the room that the player must avoid. Enemies will roam the levels and try to catch the main character.
Progress Update
By the end of the first week I plan to have familiarized myself with Game Maker and have created the main character sprite of BrainBox.
After some experimenting I have decided that 1280 by 768 is the resolution I should use, the resolution of the screen is 1920 by 1080 so if I can figure out how to snap it to full screen when the game runs my 64 x 64 sprites will be more size appropriate for the game. I want to have 64x64 sprites because I can put more detail on the sprites especially when editing them in GameMaker's sprite editor. I have decided in the end to reduce my sprites size back down again and just have a windowed screen.
I more or less scrapped all of the work I mentioned in the last paragraph. In the end I decided on a room size of 1024 by 768 and attempted to use views to zoom the players view in.
I created the main character sprite which was inspired by these images. From top to bottom they are: Robobrain from Fallout 3, Brian the Brain from Cel Damage, Wall-E and a bomb defusal robot.




Here is the design for the main character Brainbox that I came up with. The original

This was more of an original concept design than a final image. In the end I had to change the image to adjust the dimensions of the sprite. This is because the original image was far wider than it was tall. This meant that if I was to create a maze game around this sprite the paths in the maze would have to be rectangular. This would deviate from the norm of what a maze looks like as normal mazes have square paths of uniform size. This is the final version of BrainBox that I settled on.
Notice how the arms are much closer to the main body of the robot and the main body is actually taller to give a more square shaped sprite.




Monday, 24 November 2014

Maths Maze Game Assignment Progress Week 4

By the end of this week I aim to have created most of the levels in the game. This means programming the objects and creating the level geometry. In the second level I wanted some simple enemies and obstacles to overcome so I started exploring the use of paths and objects. I added in the lightning bolts and tesla coils to add a simple horizontal back and forth moving enemy. This is the simple path of the lightning bolts
I then created several lightning bolt objects that have varied speeds but use the same path. This is a quick walkthrough of the first level. If the player is hit by the lightning bolts they are sent back to the start of the level.


In level 3 I decided on a simple maze design. My initial idea was to have the player search a maze for particular collectables such as wire cutters and then chase a moving bomb around the maze to try and defuse it. I could not make this work however as when the player collided with the moving bomb, if they got the maths question wrong then I wanted the bomb to move off in the opposite direction. I couldn't figure out how to do this and the result was when the bomb collided with the player they got stuck together and neither could move. I decided instead to have a moving bomb that the player could not interact with and when the player found the wire cutters the moving bomb would change to a regular bomb and become defusable. This is the Game Maker code for the wire cutter object.



  1. The event is a collision with the BrainBox object which is the main character object.
  2. First it destroys the Wire Cutter object.
  3. Then it displays a message that congratulates the player and tells them that they Moving Bomb is now defusable.
  4. It then changes the Moving Bomb object into the normal Bomb object.
  5. Finally it ends the path of the new Bomb object, making it stop altogether.
 
I wanted to put some background music in the game and I spent some time picking out appropriate music for each level. I went for a distinctively futuristic sound. It was mainly techno and electro type music. Unfortunately when I tried to implement the sounds into the game, Game Maker didn't recognise the music properly and it sounded incredibly distorted and was not good enough. This was very confusing as I had tried to upload the music in mp3 format, which is a very recognisable format and is compatible with a large array of software.

For levels 2 and 4 I used lightning bolts with varying speeds. This meant that for each individual lightning bolt I had to create an individual object. This led to me creating about 10 different lightning bolt objects that had varying speeds. This is not ideal as it clogs up the object list and creates unnecessary assets that increase the file size and slow down the loading speed.

In level 3 there is a bug where one of the Teacher Enemies gets stuck and fidgets back and forth.
I don't know what causes this problem but I changed the dimensions of the object to make sure that it was not that the object was getting stuck on the walls of the maze. It didn't fix the problem so I decided that it is most likely due to the path of the object.

For the final level I did some concept designs for the final boss BrainBoss. He is an evil genius and is not dissimilar to the main character. I started thinking that maybe the main antagonist could be some distant relation to BrainBox himself, such as another bomb defusal robot that went rogue. Here are some of the concept designs for BrainBoss.
Jetpack Design

Walker Design

Main Bomb Design
I then did some basic level designs for the final level. They mainly revolve around the idea of collecting items from each corner of a small maze and then using these items to open doors or defuse bombs on the way to the final boss. The player will have to answer a maths question each time they defuse a bomb and then will  have to answer a series of questions in sequence to defeat the boss. If the player gets a question wrong they will have to start the sequence over again. Here are the concept designs for the final level.

 
These are some concept sketches made in Adobe Illustrator of what the last level of my game will be. It is a boss level where you come up against the main antagonist BrainBoss.

1.       Player Spawn: this is where the player starts

2.       Keys: the player must navigate the maze to find three keys

3.       Doors: the keys are used to open up these three doors to get to the boss

4.       BrainBoss: the player then has to answer several maths questions in succession to defeat the boss.
Below is an alternate version of this level where the player has to collect wire cutters and answer three maths questions to defuse each of the three bombs to get to the boss.––

Sunday, 23 November 2014

Maths Maze Game Assignment Progress Week 3

By the end of this lesson I am to edit sprites so they are suitable for Game Maker and to add some basic functionality to some of the sprites. I want to add animation to certain sprites and to program the interactivity between sprites such as hitting a wall or damaging an enemy. I have edited the Brainbox sprite so that it is more square shaped. This is to add uniformity to the sprite sizes and make it easier for the sprites to fit into the maze and move around without unintended collision.


These are my early attempts at trying to make the object BrainBox move. They way that I had it set up was that when a key is pressed it sets that directions speed to 4, then when the key is released it sets that directions speed to 0. However it does not work as intended as when any of the directional keys are released it sets all speed to 0. This is a problem because it means that if you release a key slightly after pressing the next key it will immediately stop your movement altogether.




I then decided to look on forums on how people use Game Maker to program simple movement functionality. I found a guide that shows the syntax of the code Game Maker uses and how to program an object to move. I then coded this piece of code that works perfectly when coupled with the "friction" function that slows down movement to a stop.

I ended up spending a lot of time trying to develop an extremely precise control system. I wanted the game to utilise a lot of tight spaces that would cause the player to feel pressured when running away from enemies or trying to quickly get to the objective. This fits in with the genre of a maze type game and so I wanted to make it so that it would be either very difficult or impossible to move diagonally, thus creating more of a Pac-Man control scheme and feel. I eventually settled on this piece of code that does not allow for diagonal movement. This is to prevent the player getting stuck on the walls in the maze. I later learnt that Game Maker has a bounce function that means that when a player hits a wall they keep some of their momentum and bounce off the wall slightly. If I was to do it again I would use this functionality as it would allow for precise navigation of tight corners without restricting the player to not be able to move diagonally. As the ability to move diagonally will give more variety in ways of dodging the enemies in the game.

I programmed the walls to just stop the movement of the main character altogether. In retrospect this is not an ideal way to program walls and the bounce and friction functions are more appropriate. However the system I used, does work with the main characters movement and it gives a distinctive "Pac-Man like feel" to the movement.

I also had a lot of trouble with the camera view in the game. I wanted the camera to follow the BrainBox object as it moved along but I encountered a problem that meant that it was recognising the BrainBox sprite as not quite in the centre of the screen. This meant that the players view ended up like this:

It turned out that it was because I had not specified that the origin point of the sprite was the centre. So it scrolled the camera according to the top left corner of the object rather than the middle of it.

In the first level I decided to keep it simple and have a door that had to be opened to progress. This door would be opened by solving a maths problem. I looked through tutorials on the internet to try and find the appropriate code to ask the player a question and then take their answer and compare it to a variable. I managed to find the get_integer() function that shows the player a question and presents them with a box that they can input the answer. The function returns the answer which I then saved as a variable called "answer". I then wrote an "if" statement that would run if "answer" was the same as the actual answer to the question. This would then destroy the door object and give the player a "well done" message. I then wrote an "else" statement that would run some code that would give the player a "wrong answer" message and the doors would stay the same so the player would have to attempt the question again. Below is the code described from the door object

answer = get_integer("What is 90 divided by 10?", 0)
if answer = 9
{show_message("Well done! You got it right!")
instance_destroy()}
else 
{show_message("Oops wrong answer, try again.")}

Here is a video of the door object functioning in the game.

I wanted to animate all the objects in my game but I decided that this was not a necessary feature and so prioritised other aspects. I decided that if I had time at the end of the game's creation then I would animate the other sprites. I did however animate the main character BrainBox. I did this by starting with the original sprite in Adobe Illustrator and changing them partially and then saving the new image. If I was to do this again I would most likely copy the original image and leave that as the background as I am drawing the new sprite. This would help me to visually compare the two animation frames thus contributing to better precision and a smoother animation. This is a picture of all of the animation frames that the object BrainBox uses.


This is a breakdown of the first level of the game. There isn't any combat and there are not many difficult elements as the first level is just meant to teach the player the controls and how to interact with the environment.
  1. Player Spawn: this is where the player starts in the level
  2. Hint Board: this is an object that when the player walks into it, it tells them hints about how to progress further in the game
  3. Door: this door is opened by solving a simple maths puzzle that introduces the player to the question and answer mechanic of the game.
  4. Enemy_Teacher: this is an enemy that moves up and down to introduce the player to the enemies and how they should expect them to move.
  5. Wall Arrows: these arrows point the direction in which the player has to head to progress to the next level. They also force the player to move sideways which will make certain that the player is familiar with the movement system i.e. they realise that you cannot move diagonally.
  6. Next Level: these are invisible objects that progress the player to the next level when the main character object touches them.
  7. Easter Egg: this is just a little secret image of Pac-Man in the game. I thought it was appropriate considering the style of movement that I went for. The easter egg is not visible when the player starts the game because of the view that I used. So they would have to ignore the impulse to walk towards the door or the hint board to find this mini secret. 



Tuesday, 4 November 2014

Maths Maze Game Assignment Progress Week 2


Game Design Doc

Week 2 Lesson 1 November 3rd:

By the end of this lesson I aim to have finished many of the sprites that I will use in game. I have currently completed the main character sprite and so the priority for this lesson will be enemy sprites and walls and environment sprites. I have managed to create a decent wall sprite and a detailed enemy sprite. I spent around the entire lesson of three hours on creating the enemy sprite. My focus is to create exciting and interesting main character and enemy sprites to engage and immerse the player.

Here is a screenshot of some of my sprite creation, it is the sprite of a cyborg teacher. Here you can see I used shapes to form a basis for the design and then used brushes to build up some colour and shading for each part. I made each part of the sprite individually so that I can modify them at will and this will also help with animation so that I can edit parts of the sprite without having to create a whole new one.

I created a basic wall sprite that can be used as a basis for any other wall sprites that I want to use. I then created neon coloured wall sprites that set the scene of a futuristic school with such things as cyborgs and robots.

The enemy cyborg teacher sprite as I am making it and when it is complete (below)
 
 


Wall sprites (below) basic wall, neon wall green, neon wall green (flipped) You can see how the two green walls would interlink together creating a pattern. This was intended to appear as if some sort of power supply is running through the walls. 
 
 
 
Below are some images I used for inspiration for my enemy teacher sprite. You can see the likeness to the teacher with the moustache.

 
 
 
Week 2 Lessons 2 & 3 November 4th & 5th:
 
For these shorter lessons I am continuing on with creating sprites. I have nearly created all the sprites that I need for the enemies and characters. If I have more time left over in later stages I will create boss sprites for boss levels, but my main priority is to create a working game with some attractive sprites first. I first re-skinned my enemy sprite to create a similar sprite that was easy and quick to make but adds some variety in enemy type. I did this by adjusting proportions and changing certain features and changing the colours of the sprite. This has saved lots of time than if I created a whole new sprite. (Below) The Enemy Sprite (Alternate Skin)


.
This is the process of me drawing a sprite. The sprite is a corner wall part that is meant to resemble a tesla coil.
 

 
As you can see I start by drawing a basic outline for the bulb part and the nucleus part. It is intended to look like a tesla coil which I will add detail in later. At this point I actually lost my work. I saved my work in a different file by accident and could not find which file I had saved it to. This meant that I had to start again on this design and wasted valuable time that could be used in Game Maker.
I then added in some detail to make it look like the electrical energy moving through the sphere. I then grouped together everything I had done and made it slightly transparent to give the impression that the it is behind glass.
 
Next I added an extra layer for the outline and some glare effects on the glass to make it look more 3D and realistic.
 


 

 

I then created a base for the design with a lightning bolt on it. This is to signify that in game this sprite will be used to shoot lightning bolts around the level that the player must avoid. They will look much like the lightning bolt on the base.

Finally I added some more colour to the sprite with grey in the box and blue and red microchips. This sprite is now complete and can be put into Game Maker.

I then copied and scaled up the lightning bolt to create a separate sprite that will serve as the lightning that jumps between tesla coils.

Here are any leftover sprites that I created for the game.