Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

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.