RedDragonMakesGames

  Get it out! The concept: This week, I was given the suggestion of doing some kind of sliding block puzzle. One approach to this would have been to build up a framework, and then create a few positions and allow the player to play through them as seperate levels. That wasn't the route I went down; instead I decided to create a game that would automatically generate its own positions for the player to solve. The challenge: The big challenge here is of course finding a way of generating puzzle positions, but first I needed to decide on a format for the game, and build up a framework. I decided the puzzle would involve a grid containing a number of balls that would all move together on a key press, and the player would have to work out how to move the balls in such a way that they will only enter allowed cells, while trying to move all of the balls out of the grid through holes in the edge. While setting this up, I made sure to work on variable grid sizes, to allow the size of the gr

  Asteroid Universe: The Concept: Do you know what shape the universe in the game asteroids is? I found out when I was younger by watching the Royal Institution Christmas Lectures that it's actually a donut. If you project the game onto a donut, you'll find that if you go off the top, you come back on the bottom, and if you go off the side you'll come back on the other side, just like the game. But what if the game universe was a different shape? This week's minigame experiments with that, allowing you to change the shape of the universe as you play. The Challenge: So to change the shape of the asteroid universe, first I needed to recreate the game. I started with the ship physics. Controlling rotation was simple, drawing the rotated image less so. The issue with rotating the image is that pygame images are by default positioned at their top left, so if you rotate them, they rotate around that, rather than around their center. This needs to be accounted for when rotatin

  A Shade Different: The Concept: This was actually an idea suggested by my sister, after seeing the concept on TikTok.  You are shown a number of blocks of colour, one of which is slightly different, and you have to click the different one. Simple, right? This was a slightly quicker minigame, as I'm also working with a team for Game Off 2020, so look forward to that at the end of the month. Ironically, given the title, it's also very similar to Moles in Holes in terms of mechanics; the player's goal is to click on the right area of the screen. However, in this game rather than testing the player's reactions, it's testing their ability to see colour. The Challenge: As this game is mechanically similar to Moles in Holes, I was able to treat it as an exercise in adapting and repurposing code. One nice thing about doing this is it gives you a chance to review and check your previous code. One small thing I noticed was about the ordering of functions. In python you can

  Moles in holes: The concept: I wanted to make a minigame with a little more polish this time, so I decided to make a configurable wack-a-mole game. The game itself is pretty standard: Click on a mole, it goes away and you get a point. Missclick, and you lose a point.  The challenge: I wanted to put some effort into making sure the code was super clean. One way in which I did this was using helper functions to avoid duplicating long statements. For example:     def GameCoordToScreenX ( self , x ):         return ( x * self . hole . get_size ()[ 0 ] + ( x + 1 ) * XSPACING )     def GameCoordToScreenY ( self , y ):         return ( y * self . hole . get_size ()[ 1 ] + ( y + 1 ) * YSPACING + TOPBAR )     def GameCoordToScreenPos ( self , pos ):         return ( self . GameCoordToScreenX ( pos [ 0 ]), self . GameCoordToScreenY ( pos [ 1 ])) These functions allowed me to avoid hard to read functions, especially in cases when x and y are already somewhat complicated, such as the