When and how to use them.

Have you ever been requested to do a change to a system, but that change should not be visible until it is completed? Have you also been requested to launch fixes to the same system while you are changing it? Then you probably faced this problem.

Introduction

We have all been there: someone asked us to add some feature to an existing system, but that it should only be visible when it is completed. You go off and start coding. Sometime later, that same someone asks you to fix a bug, a high priority bug. But you have your code half done, and you can’t simply stash it. How will you handle this?

Have you ever wanted to write your own games? Join me on the quest to sharpen my skill while having fun building games!

Context

In my quest to get back to coding, I decided to start building games again. The last time I wrote about this adventure, I summarized the latest changes I made to my version of the blocks puzzle. A few months have passed since then, and I have been busy thinking about what my next step should be.

As a software developer, you should always be on the lookout for new things and new technologies. You shouldn’t use all of them or play with all of them (who has the time?), but at least be informed of what is out there. You should also try new things from time to time, just to keep the curiosity juices going. This article summarizes my foyer into a new programming language, Rust. I will give you a small background, why I was curious about it and if the advent of code is a good way to learn a new language (tldr: it is!).

Welcome to the last installment of building a Block Puzzle! In our last article, we made the game playable, but it was a little monochromatic. Today, we will be changing that. We will add color, scores and sound. Finally, you’ll be able to play the game yourself!

Adding some color

Adding some color to the game is quite easy. Since our game pieces use sprites that are made of string, we can simply make a mapping between a letter and a specific color. With that mapping, each piece can have its own color, and our game bursts with color.

Welcome to another installment on building a Block Puzzle. We are continuing the series of articles that describe the process taken to develop a Tetris-like game.

In the previous article, we made the game almost playable. It was almost playable because we could interact with it, but the logic to remove completed lines was not there. In this article, we are going to add several types of pieces to the game and the logic that detects full lines and removes them.

Welcome to another article on building a block puzzle. This is a series of articles that describe the process taken to develop a game similar to Tetris (you can find all parts of this series at the end of the article).

In the previous article, we developed the base model for our game. In this article, we will be creating the UI for the game. The UI will use the model previously developed to make a playable game. It will not be the complete game, but having something you can use and play with enables faster feedback. We need feedback to know if the model is easy to use (it should be, because we wrote it using Test Driven Development), but we also need feedback on what’s the next functionality that we should develop. I prefer to do development in small steps and collect feedback as I go, even when I am doing it alone.