RedDragonMakesGames

 Armageddump: Game Design (The main post about this game can be found here) The context:  When I joined the team for this jam, it was very much as a programmer. I was suprised to find myself in quite a large team, although that was explained somewhat because the discord was a team that had done a number of previous jams together, and people would either take part in a jam or sit it out, either completely or only offering advice. The work for this jam was also quite split; there were a lot of artists and composers for instance, but each only created assets for one boss or so, meaning it roughly equated to fewer people putting more time in. After the jam started and the theme was announced, some of the ideas were amalgomated into the concept for our game. The project manager wrote a rough description of the bosses, with some attacks outlined but little more detail than that. To flesh out the game enough to start programming, a designer was invited to the project, but the concept didn'

  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