Hello everyone!

This is my very first devlog for the first game that I plan on commercializing. It is called Treasure Breaker, and it will be a mobile app game that I am developing solo. I am applying the Scrum methodology, working on the game in two-week sprints, with a devlog done at the end of each sprint.

(You can skip to Game Background if you want to just read about the game I'm making).

About Me

My name is Ahmad El-Baher, and I have recently graduated from Concordia University (Montreal) in Computer Engineering. Being an artist at heart and one who enjoys playing video games, I picked up game development as a hobby, through which I learned how to program. From there I made several games and joined some game jams as well, but I was indecisive about the prospect of professional game development for a living.

I decided, in the end, that I would like to try creating and selling my own games, and see where that goes. At the same time, thankfully, I am working full time at Ericsson as a Services Professional (basically advanced tech support). While it makes game development more difficult, this job will serve as my source of income, my source of funding - should I ever need it in a game I'm working on - and my backup plan, in case this doesn't work out.

I have already done the mistakes of first-time developers in the games I have made previously, including: over scoping, focusing more on additional features/aesthetics than the game play, bad sense of difficulty, etc.

You can find these games at my itch.io page: https://gamecoder95.itch.io/

Game Background

Treasure Breaker is a game I made for a week long game jam organized by the Game Dev Network (Discord link, if anyone's interested in joining: https://discord.gg/q5zRH3) on itch.io that had the theme "Hidden Things". My game was essentially the classic "Brick Breaker" game with a twist: instead of destroying all the bricks on-screen, the goal is to find a specific "treasure" brick, hidden among all the bricks, within the time limit. The way to do so is to destroy bricks and observe their destruction animations:

- A "explosion" of just dirt indicates that the treasure brick is still far away from that brick.

- A "explosion" of dirt mixed with gold dust indicates that the treasure brick is near that brick, but still several bricks away.

- A "explosion" of dirt mixed with gold dust and gems indicates that the treasure brick is very near.

Then, finally, when the treasure brick is destroyed, lots of gold coins spill out, indicating a victory. If the player runs out of time or all their lives, it's game over.

One tool to help the player are 3 "magnets." Because the player has no control over where the ball goes except for the initial launch, the player can press Space to return the ball to the paddle to launch it at another area. This action consumes a "magnet." When the ball is on the paddle, the player can launch the ball straight upwards, diagonally to the right, or diagonally to the left, giving a little more control over the ball to the player.

Some game play of original Treasure Breaker game jam game.

Quite shabby overall, but I'm proud of having submitted something. You can play this game at the following link: https://gamecoder95.itch.io/treasure-breaker

The New Project

After finishing that game for the game jam, I realized that this is a simple idea that can be made into a fun and challenging mobile app, which I now began to work on. However, I have many design changes planned for the new version of the game, with the biggest of them being that I want the focus of the game to be solely on finding the treasure brick in the fastest possible time. I don't want the game to be narrowed down to "destroy all the bricks and the treasure will inevitably be destroyed," but rather "what can I do to find the treasure brick faster?"

This will be done by giving the player as much control over the ball as possible and constricting the time limit such that they can't break all the bricks in the level, even if they tried. I feel this will make it a more interesting and challenging game as opposed to a mindless casual experience. Furthermore, any bonuses/power ups acquired will be used to destroy specific sections of bricks rather than an indiscriminate bunch, and hazards will reduce the time given to complete the level.

My vision for the final product will be composed of a number of levels, where each level has a unique layout of bricks, with one or several treasure bricks hidden among them.

Progress Thus Far

Finally, onto the good stuff! My short term goal at the moment is to make the most basic, playable level of my game with the new design principle. Here are the features I plan to add/change from the old game to create the minimal, playable level of this game:

- No lives: time will be the only "obstacle." This means that the bottom edge of the screen acts as a wall that the ball can bounce back from.

- Quadruple Paddle System: Rather than a single paddle to hit the ball back, there will be a system of four paddles surrounding the bricks on each edge. The top and bottom paddles move simultaneously, as well as the left and right pair. They are closer to the middle of the screen such that it takes less time for the ball to rebound from a paddle than it does to rebound from an edge of the screen. (Side note: this is not really an official name, it's just what I call this feature for the sake of documentation.)

- Better treasure brick selection: rather than choosing a treasure brick completely randomly, a few select bricks will be marked as "potential treasure bricks" and one of them will be randomly chosen at the start of the level.

So far I have completed the first of these features, and have nearly completed the second - I am in the middle of adding touch controls to move the paddles. I created dummy sprites for the touch buttons and placed them on the scene. I just have to write code for them now.

Progress so far: the Quadruple Paddle System with its positioning and limited movement.

The bricks will be in the middle of the paddles, with the distance between the paddles being adjustable by code. Otherwise, yea...there's still much to be done, but I will hopefully get there!

Theme

This will be more relevant later on when it comes to the art, but I think the theme that will fit the best with this game is ancient Egyptian treasure hunting. In fact, I already made a title screen for this game with that theme in mind:

Treasure Breaker title screen.More specifically though, I am debating between these two specific themes:

- Archaeologist searching for treasure.

- Egyptian pharaoh tomb robbery.

I am inclining towards the second one as it makes more sense to have a time limit for it. One idea to add on top of that is to visually show the level of difficulty increasing by having "increased security," and shifting the visuals from more ancient times to more modern times.

Up Next

Firstly, next devlog will get to the point more quickly. I rambled on quite a lot here, as this was more of an introductory post to myself and my game. So from now on, excluding exceptional cases, I will only cover the major updates to my progress.

Secondly, I plan to get the movement touch controls working and the improved treasure brick selection as well by next sprint. With work + fasting for Ramadan it will be tough, but I believe I will be able to do it God willing.

That's all for now! Thank you for reading, and I'd love to hear your feedback and input as well!

Hello everyone!

In this sprint, thankfully, I accomplished quite a bit of stuff! I completed what I had trouble doing so from last sprint, and began implementing some more features. Unfortunately, I also slacked off in a lot of the days, focusing on either other things or being too lazy to work on the game. As slow as it was, I, at the very least, have something to show for it.

Game Background

A quick, little summary of the game I'm making:

Treasure Breaker is essentially a spin-off of the traditional Brick Breaker, with the goal of finding a specific "treasure" brick hidden in plain sight among the rest of the

bricks within a time limit, instead of destroying all the bricks on screen.

This Sprint's Progress

At the end of last sprint, I began working on basic touch controls for moving the paddles. In this sprint, I have completed them, and also managed to create a successfully working basic build for Android. Creating this Android build

for testing the touch controls took much longer than I expected, and was a cause of unforeseen frustration, so thank God I tried that early!

After a few days of fruitless building and testing for Android, the issue ended up being that I had "Auto-rotate" as the rotation setting for the Android build within the Unity editor. This was messing up the positioning of the paddles

because in the code I positioned them and limited their movement using Screen-space coordinates - with "Auto-rotate," the game would take the screen width of the phone in portrait mode and use that to limit the paddles' horizontal movement

(the similar effect also occurred to the paddles that move vertically), so this would offset the paddles' positions very oddly when I try to move them using the buttons.

So the solution was simple: force the game to be in landscape mode! This killed two birds with one stone: having the game in landscape mode - which was better for what I was making - and fixing that annoying bug.

Moving on, after finishing up with the paddles, I then moved on to adding the ball. My goal for this sprint was just to have the launching feature of the ball, the ball's movement on screen and collisions against the walls of the screen and the paddles, and the ability to be "placed" on any of the paddles so that it can be launched again. For now, launching the ball is implemented as simple as possibly, with its direction being perpendicular to the paddle that it is on.

These tasks I had for myself were not so bad given that most of the basic functionality of the ball had been implemented before in the previous version for the game jam. I simply took the script for the ball and cleaned it up for this new version, as well as some general improvements given whatever knowledge of C# I gained now compared to before.

I then added some simple code to place the ball on a paddle of choice, launch the ball, and reset the ball on one of the paddles. This worked really quite well and I was able to test it quickly, before I moved on to the more tricky part: the management classes.

One mistake I've kept making in earlier games was simply mismanaging my code and my classes. I would have them tightly coupled with each other, have multiple with static functions that are referenced everywhere in a disorderly way, and the components not being as modular as they should be.

For this game, and for future games, I plan to come up with a better design to solve that issue. Rather than one "Game Controller" class that is responsible for literally everything about the game, I will split up the tasks of managing the game across multiple classes. This is a rough idea of the structure I am going for:

- Each game entity manages itself. These entities are primarily the "prefabs" of the game, like the ball and paddle. They have the essential code to move themselves, and provide the necessary public functions to be manipulated accordingly.

- For entities that are related to each other in some way, a *Manager* class would handle the code that "relates" them together. For example, the ball and the paddle system are managed by the *BallPaddleManager* (need a better name though). The *BallPaddleManager* is the class that decides when the ball is on the paddle and the launching of the ball.

- Finally, the *GameManager* is like the "Big Boss" of these manager classes, where it handles the "relation" among the *Manager* classes.

This was tricky because I spent a lot of time brainstorming and on trial-and-error implementations for several ideas as to achieve this kind of scale-able and reliable structure of the game's code before finally settling with the

above, which is what I currently think is the best idea so far. I'm hoping it'll pay off in the future when the code becomes larger than my hopes and dreams so that it'll be easier to rummage through it to debug and add on to thecorrect areas.

And that's about it for now!

Up Next

I plan to accomplish these goals in the next sprint:

- Finish up the code for the management classes.

- Add in the touch controls for placing the ball on a paddle and launching/resetting the ball.

- Add in the bricks.

I also came up with a lot of ideas randomly that I put on Trello. Most of them are currently irrelevant, but the one that I feel is most important to try and implement are better touch controls for paddle movement.

Even though I was happy that the touch buttons worked on my smartphone, I didn't feel that they were practical for the game - they were too slow and awkwardly placed. They also take up nearly a quarter of the screen space combined.

I am thinking of replacing them in the future with dragging controls. They would not only be smaller, but allow the user to comfortably move the paddles at the speed of their fingers, which is much faster than pressing and holding a button to make the paddle move at whatever speed they are programmed to move at.