RedDragonMakesGames

  Covert behaviour: The concept: I've been doing some studies into behaviour trees in Unity for one of my personal projects, so I figured I'd experiment with the framework I'd created (using this tutorial as a guide (I did notice that the GetData and ClearData functions seem to doing unneeded work - they call the parent function, which then calls its parent function and so on recursivly, however they also loop upwards individually in the original function, so it seems like the functions might be being called multiple times on nodes close to the root. I rewrote the functions for now, and I'll look into it more as I use data in the BT. (P.S sorry for the nested brackets, but I guess I am an programmer :P))). I decided to make a stealth game, where enemy behaviour was controlled by a behaviour tree. Enemies would patrol, and charge at the player if the player crossed their line of sight. On top of that, I added a panic mechanic; if the player reached certain spots, all th

  Armageddump   First boss gameplay Armageddump is a 3D first person boss rush, developed in Unity. As part of the team working on it, I took the original concept and designed the bosses, gameplay and story and fully programmed the second two bosses. The programming included boss AI and management, developing the arenas and props and adding models, animations and sounds. The assets and code for this game can be found at https://github.com/RedDragonMakesGames/Boss-Rush-Jam . Game walkthrough: Blog posts about Armageddump: Game Design

  3D Tetris: The concept: I wanted to do another full sized minigame now that the game jam has finished (expect a post on that later in the week). This was actually an idea from my father, and it gave a number of interesting programming challenges so I decided on it as soon as I heard it. The idea itself is explained pretty well by the title; tetris, but in three dimensions. The challenge: The first issue for this game was how to represent the grid. I could have had each square control itself, and consider squares around it to decide when layers should be cleared, but I decided to have an overaching controller to handle it. I instantiated a cube in each possible spot on the gameplay area, and then used the controller to enable/disable the cubes and set their colour. Although doing this did involve a number of loops, as the game won't have large dimentions these loops won't be so large. As well as that, instantiating the cubes at the begining and enabling/disabling them is more

  21: The concept: Seeing as I wanted to spend time on the game jam this Monday, I decided to do something very simple. My task was to create the card game 21; nothing unique, but a good chance to practice efficient programming. To give a quick summary of the game, you are dealt two cards, and can draw additional cards. The aim is to get as close to 21 as possible without going over. There are a couple of rules that added a bit of depth to the programming (for example aces can be either 1 or 11), but on the whole a pretty simple task. The challenge: I did want to handle the deck in the most effecient way possible and avoid making the shuffling more complex than it needed to be. I decided to use a list to store the deck, because lists, unlike other storage containers, are able to efficiently add elements at a given point with constant complexity. This allowed me to shuffle the deck in a single for loop without the added linear complexity of adding the elements that using vectors would r

  Round And Round: The concept: Another shorter minigame this time, as I'm working on another game jam game, expect to see that in a couple of weeks. I felt like making a racing game in python for this one. As I was making the game, I thought it would be cool if the player could draw their own maps.  The challenge: The first challenge I faced was getting movement for the car that felt responsive and fun to play. Getting the car moving wasn't too difficult; just a matter of adding functions to the arrow keys to control the car. For the left and right arrows, this would change a rotation value stored in the car class. I used a momentum variable to store the movment of the car; as it turned out, this didn't end up being too different from its speed in the rotation direction, but theoretically you could make these values differ to allow the car to drift or spin out of control. For accelerating and breaking, I used some basic trigonometry to properly effect the momentum in the d

  Delegating: The concept: There's a system in C# called delegates, allowing you to define a variable that can be called as a function, which can call a range of methods that are assigned to it. I hadn't used delegates in any Unity projects before, so I figured I'd make a minigame to demonstrate the system. As it happened, I took it far too literally. I figured I'd set the player a series of tasks, which they could either attempt themselves, or delegate to an AI, which would handle the tasks using (you guessed it) a delegate.  This meant that my minigame for this week wasn't exactly one minigame, but instead six simple minigames. This meant a bit more coding and set up than I expected; in the end I wrote eleven separate scripts for this project over two scenes, and suprisingly little of it involved delegates! The challenge: Despite my intentions, the biggest challenge here wasn't using delegates, but instead creating six separate minigames to use them on. I dec