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.