Just before Christmas, the school of computing at my university ran a small game programming competition, and I decided I
would enter it.

Like all competitions, there were rules and limitation in place, so lets quickly go through these now.

Rule one, we had to use python using a library called graphics.py, which isn't exactly a good library for making games at all,
as it was specifically created for education and so is very basic, and you are limited in what can be done.

Rule two, we were not allowed to use other libraries such as pygame

Rules three, we were not allowed to create our own classes or types, which while annoying, it was likely in place to keep
the contest fair for everyone as we hasn't covered classes yet at university at the time of the competition

And lastly, for some reason it had to be a game about an Android eating apples or a squahs ball game.

and as you have already seen in my last video, I decided to go with the former option

So without any further ado, lets get into this




To start off, I wanted to create a game state system to make easier to organise different stages of the game ,
such as the main menu and the game itself

Now, as mentioned in a previous video, I always implement this kind of system using polymorphic classes, but of course
the rules of competition would not allow this, so I had to find another way.

What I did instead was created some constants to represent an "ID" of a game state, as seen here. I could then set a variable to
one of those values, and jump to the different functions for those states using some if statements

After this, the next thing I wanted to do was create some code for the player and drawing the Android character.

I don't know why I did what I did, but I probably really overcomplicated this. Rather than just loading up a image, for
some reason I decided to load  up vertex positions of the Android from a text file and put them in to a polygon object.

While completely unnecessary, it was quite fun to implement anyway, and it ended up working just fine,

Now I had the player drawing, it was time to actually get it to move around using keyboard input. Usually this
is really simple to do, but I had to graphics.py, which doesn't have very good keyboard support.

This means that I would hit a key to move the player and it would move a it, stop for a second, before starting to move again.
This kind of thing feels awful for responsiveness, so I tried the best I could to fix this using some tricks with
velocity values.




Now that I had the basics, it was time to actually think about what I wanted the game to be.

This was quite hard to do, as it had to be a game about an Android eating apples, but I wanted to be a bit more
exciting than that.

And so, I decided to make the game similar to something I made a very long time ago, in fact one of my first videos on this channel


This was a simple game called Pyoro, and I thought I would simply put my own twist on this for the competiation game

My take on the concept was fairly simple. Apples would fall from the sky, and you would catch them. For each apple
you catch, you get a point. However, if you missed an apple, then it would destroy the tiles the player walks on.

When tiles are destroyed, it limits the are the player can walk. If the apples get past the tiles, you lose a life.

Run out of lifes and it is game over.

So, in the video right now I have been creating the code for apples falling from the sky, and then destroying tiles the
player is walking on, as well as making it so the player cannot walk on destroyed tiles.

And this can be seen working here. The apples destroy tiles, and the player is then limited to where they can walk.

Another thing I wanted to add was the ability for the player to throw apples that they had caught at the apples falling,
before they hit the tiles. However, the penalty for this is -1 point.

Players would be able to aim where the apple is thrown by using the mouse.

This was done using some simple vector maths. First
I took the X and Y difference between the player and the mouse, and then I would normalise this vector to make its
magnitude equal to one, and then multiply the vector by a scaler speed value which would result in the final velocity
of the apple.

This would make the projectile apples always travel at the same speed, no mattter where thrown.




The next feature I wanted to add were different apple types.

For now, the only apple game in game was the one that added one point, which was kind of boring, so I wanted to add some more.

Now, this sort of thing would be very easy with classes, but again, I was not allowed to use them. So I had to ask myself,
how on earth am I going to differ between apple types in the code?

So, my solution was to have different apple types to have a slightly different radius. In the graphics.py module, the
apples are
drawn using a Circle class, which hasa function called "getRadius()", which allowed me to differ the types.

--

The apples are drawn using a class defined in the graphics.py module called "Circle", which has a function called
getRadius(). So, after creating the different apple types using a different radius, I could then differ the types by getting
the circle's radius when needed.

The  new apple types added can be seen here.

When the player collects the red apple, it just adds score as usual, but
collecting the green apple repairs all the broken tiles, and collecting the yellow apple adds some lives.

After this, I wanted to add some kind of game over screen and a main menu. The main menu would have different options such
as play game and exit game, and the game over screen would show the player's score, and then give the option of playing again
or returning to the main menu.

However, before I could actually implement these menus, I first had to actually implement the components a menu needs, such
as buttons.

The first basic version of the main menu and the game over screen can be working here, using buttons

However, it was looking very bland, and so I decided I would make it look more exciting by making apples
fall in the background of the menu.

After this, i decided I would try add some kind of highscscore system to the game. This would allow players to
submit their score after they get a game over, and see how good or bad they are compared to others.

To do this, I present a text box for a player to enter their name if they want to add themselves to the highscore. It will
then load up the highscores from a file into a dictionary, and then add the player's score to it. Finally, I sort
the scores into decsending order before rewriting the scroes to the file.

The submission screen for the highscores can be seen here.


The final thing I wanted to do was actually make the game look good, rather than how bland it is currently looking now, and so
I opened up good old paint dot net and started making some images for use of the background of the game, of which the ones
being shown created here didn't actually end up being used.

And well, the finished game can be seen being played now.

As you can see, all of the menus are fully implemented, such as the how to play menu, and the highscores, and it is
looking a lot better now that I have added a background.

So anyways, I hoped you enjoyed the video. Also, I am sorry I have not uploaded a video in a while, but university has kept me
very busy, with all the coursework and social side of things.

And lastly, I just want to espically thank all my Patrons, who have continued to support me dispite my lack of
uploads in last few months, so thank you have everyone listed here.