RedDragonMakesGames

  Hi, it's been a while... So what's new? Well, for the past three years, I've been employed as part of the Near Light studio at nDreams. I've really enjoyed being part of the team and making some incredible games (more on those later).  Unfortunately, I've been informed that my role is at risk in a proposal for studio closure, so now seems like a good time to update you on what I've been doing during my time at the company. I might also have a few more personal projects coming to depending on how things work out, and I'll be posting about some of the specific features I've worked on in the coming days. But for now, I'd like to introduce you to the games I've been working on! Frenzies: Frenzies is the game I was hired to work on originally. I joined the project as a junior coder soon after it started, when it was still using the Unreal Lyra default models and had only example maps. I worked on the game until it was released to the public in Octob...

  Getting it back: The concept: I returned to Unreal for this one; I decided I wanted to use the engine before I decided on the concept, but I soon came up with the idea of doing a volleyball game. This gave me the chance to experiment and practice a bit more with physics in unreal, and manipulating objects as desired. Unlike previous games in Unreal, I didn't tie myself to using C++ or blueprints, and instead decided to just use what made the most sense to me at the time. Suprisingly, I ended up using blueprints a lot more than I expected, I think because some of the logic behind them was starting to click with me, and I understood more that I could consider blueprint hierachy the same way as hierachy in C++. The challenge:  The first thing I looked at for this game was the physics, and making the ball feel the right amount of floaty so that it was possible to hit back, but also allow it to fly at a decent speed so that the player could add a decent amount of force to it. I p...

 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...

  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 wou...