RedDragonMakesGames

  Snaker: With the minigames I've made so far for MM, I've used Python and pygame as an easy way to quickly write simple games, something the language is great for. However, one downside to writing games in Python is that they can't be played in browser. I took a look into ways around this problem, and the main issue is that normal pygame operation would involve blocking browser updates, thus making it impossible to embed. While there may be ways to get around this using slightly different libraries, it would require a lot of refactoring code to fit. So instead of trying to use a language not designed for web apps, why not just switch to one that is? I decided to make a game in JavaScript using Phaser. ...tiny problem, I hadn't used Phaser before, and slightly bigger problem, I also hadn't used JavaScript, so making something at all playable using a language and framework I was completely blind to in a single day might be a bit of an ask. But I wasn't going to l

Build a body Build a body was the first full game that I made, during lockdown. I wanted to make a full game in Unity, making all the assets myself, and using C# to tie them together. Seeing as I had no knowledge of 3D moddeling techniques, I knew that the bulk of the actors would need to be made out of primitives. I soon arrived at an idea where the player would start as a simple ball, rolling around, and then could find other primitives (cylinders and a block) with which you would construct a body. The order in which you find the other objects affects what you turn into, and each combination of objects has a unique way of moving. The player hopping between hills The player as a ball by the river The two images above show some of the objects that move by using Unity physics. The ball rolls around with an impulse added by the player's controls, and the hopping ball is similar but instead only moves when in the air after the player has jumped. One thing that was really useful for me

 As promised, in this post I'll be talking about the gameplay in Imperfect Control. As the name suggests, I wanted to do something different with this game rather than creating a typical roguelike where the player moves around the rooms. Instead, I had the idea of having the player move the enemies. Each room then becomes trying to perform the correct movements to destoy the enemies (by moving them into hazards), while at the same time making sure the player wasn't hit by any of the enemies.  Spawning: I wanted each room to have a separate parameter (which I called hazard level), detailing how difficult each room would be. Each room could then be generated with a seperate value as part of the map (Part of the reason for this was that one of the powerups I was hoping to add would reveal the hazard level of nearby rooms, unfortunatly I didn't manage to implement this). To control the spawning of each room therefore, I assigned this hazard level, and therefore the spawning, to

  Cryptic: The concept: This time, I wanted to make a game that flexed my creative muscles a bit more, even if that meant having a slightly lower coding intensity. I decided to make a text-based puzzle adventure, where you have to type an answer to a situation, with clues contained in the text, and also in simple pictures. As well as each individual prompt having a solution, I wanted it so that the final question (minor spoilers I guess :P) involved all of the previous parts, so required a bit of memory, or noticing the connection as you went along.  The challenge: Coding wise, this wasn't too complicated, but that doesn't mean there weren't chances to be efficient. I did this by seperating the game into two python files, a framework and a level manager. That way, the framework could handle input and drawing the screen, while the bulky text was seperated in a different class. One issue I did encounter was that of word-wrap, so long strings of text would move onto the next l

This was the first game jam I've taken part in, but I'm pleased to say that I'm cautiously happy with the results. There were a lot of things I'd like to have added, but as is to be expected I ran out of time for them. On the other hand, I was pleased that I managed to create the core elements of gameplay and random generation, with at least some scene setting involved, even if it was through my kinda crappy paint drawings. Talking of paint, here's the (not great) splash screen I hurriedly made: You can play Imperfect Control at https://reddragonmakesgames.itch.io/imperfect-control . I might talk about Imperfect Control in a couple of posts, because there's quite a bit to talk about. In this post, I'm going to talk about the random generation. Random map generation: "Rougelike" refers to games with procedurally generated levels, so this was one of the first things I looked at when creating this game. The first script I wrote had the following funct

  Pong of war: The concept: Seeing as I was working on a game for the Roguelike Monthly Jam, I went for a simpler minigame this time (That's also why I didn't get this post out earlier in the week, sorry about that. Expect a post about the game jam game soon!). I decided I could reuse some of the code from Break-in and make a pong game. The twist I decided on was that there would be a third paddle, in the center of the screen, that both players have control over. So if one player moves up, and the other down, it doesn't move, but if both hold up it moves up at twice the speed and so on. (Hence Pong of war; like tug of war, get it?) The challenge: Ball physics and rough bouncing physics I could take from Break-in, but one thing I needed to add was the ability to change the angle of the ball. To do this, I took the location of the impact along the length of the paddle as a ratio, and then used that to adapt the speed accordingly. The AI for the other player simply follows the

  Break-In: The concept:     This time I made a twist on the classic game breakout. Rather than controlling a paddle to hit blocks with the ball at the top of the screen, instead you would control the blocks themselves at the bottom of the screen. As before, if the ball gets past the blocks, you would lose (or as I later decided was fairer, lose a life). Again because of needing a simple graphical interface, I chose Python and pygame. The challenge: The complexity of this minigame comes from implementing the physics of the ball. As is quite common, I decided to calculate positions in line with draw calls, so every loop the input would be handled once, the movement of the ball would be updated once, and the screen would be drawn once. I decided that the ball at the start should be moving with a set speed, but in a random direction, so I added a bit of Pythagoras to allow this to be a settable parameter in the code. The details of the ball can be given by two tuples (for people more used

Minigame Monday:      To make sure I keep producing code, games and therefore blog posts, I'm aiming to create a small game every week on Monday (although it might not make it on to the blog the same day). These games will obviously be pretty simple; so far I'm thinking of making some twists on classic games, but that will probably vary. With regards to engine/language, I imagine many of them will be made using Python and pygame ( https://www.pygame.org/ ) due to its simplicity; it makes it quick to get something running on the screen. I'll release the game on itch.io and the code on github (see the links on the sidebar) with each blog post, so you're welcome to try the games yourself and look at how they were put together. Don't expect amazing graphics or intricate detail, but each game should be perfectly playable and hopefully pretty fun! This week: 3D Minesweeper The concept:      The idea is pretty simple: In a normal game of minesweeper, the number in each cel