The Cake is a medium sized action-oriented Unreal Tournament Capture The Flag map designed for 8 or 6 players.
The map is designed for dramatic changes of pace and basic but balanced strategic planning. Ideally the setting of the map should be a space station or similar sci-fi ambient.
The gimmick: the cake
The gimmick of The Cake is the cake-looking structure at the center of the map. The structure works both as a simple hill where getting to the top allows for a tactical height advantage but also as a way for player to quickly get cover: going up a level gives coverage, at least until the pursuing player follows.
On the top of the cake are placed a rocket launcher and a minigun, two health packs and a redeemer. Getting to the top, however, is not free of risks. To make climbing with Translocator less overpowered and make players think before teleporting a level up, some killing fans are placed in the second ring.
The circle motif of the cake is repeated throughout the map, as all rooms are circular and even the placement of the spawning room and the flag room is based on an ideal section of a circle.
Originally the “cake” was supposed to slowly spin. The first section would spin clockwise, the second counter-clockwise and the top would stay still. This worked very well in local play, and created very interesting dynamics (notably by making the use of the Translocator much riskier) but, unfortunately, I couldn’t find a way to make the segments move smoothly during LAN play.
The spawn room
The room where a team spawns can be both used in defensive and aggressive ways. If they have a sniper rifle, defenders will be able to shoot attackers passing the bridge visible from the big window, which is wide enough to not allow defender to camp because it keeps them too exposed. Also, the room contains a BioRifle, which is especially useful for protecting the flag in the closest room. Attackers will be able, if quick moving, to gain the best protected access to the flag room.
The flag room
There are no long sight lines to or from the flag room. The reason is that I wanted to have easy enter and exit from the room. The flow of the room is very circular: all entry and exit points in the room are placed in a way that creates circular motions. The room is designed for quick incursions and quick exits. If the flag is stolen, defenders have a better chance retaking it by using the spawn room or the closest part of the main room.
I tested the map throughout development and this is the feedback I got:
The map is fun and balanced
The weapons are well chosen and placed in interesting locations – the placement of the Biorifle, in particular, was appreciated by several players
The map is small and may not be suited for teams of 5 or 6
The cake structure provides good variety of situations. Some players were slightly frustrated by the fact that it’s not always easy to climb up one level in the structure, but others appreciated that because it gives a bigger advantage to those who do climb, so I decided to not add more jump pads or ramps
I wrote an article for Made With Unity about the making of our biggest school project, the 3D puzzle platformer Apeheart. In the article I talk about some design and coding decisions I took to try and get the most done in a relatively short production time. The article got the homepage spotlight from Unity, which is a pretty cool thing.
So, let’s try to kick off this part of the site with something that might be useful or interesting.
What I would like to do in this post is break down the design of my latest game, Breaking Brix, and analyze the decisions I took and why I took them. I honestly do not know if this can be useful to anyone, but at worst it is something I can revisit in a while to see if – and how – I improved as a game designer. Also, I love when people get in detail about game design, so I want to contribute to that.
So, after launching Heads Will Roll, in a very, very minimum viable product version (stress on minimum) I felt burned out with the whole idea of making games in my spare time. A fairly basic concept of a mobile game took years to complete and it still lacked the punch, the polish and the sheer amount of stuff – please never say “content” – I wish it would have. I guess everyone making anything remotely creative sooner or later gets to the “what’s the point of it” point. One year ago, I was there. Either I quit making games or I had to change approach. I decided to change approach. I realised that what I really like is learning, and so I decided to do exactly that: focus on the process of learning and, maybe, in the meantime, this would result in better games.
Even though I had worked on three original games, this was the first time I would design and code a game all by myself, and so I took the most common advice given to absolute beginners: take a classic design, remake it and study why it works. I decided to add an extra bit to this idea: find how that classic design could be twisted in a slightly different direction. I have been fascinated by how games such as Pac-Man 256 and Crossy Road adapted classic ideas to the context of mobile gaming, and I wanted to do something in that spirit.
I decided to take the most classic of classic games, Breakout, and make a version that would make sense on mobile.
Controls had to be touch based, but instead of having a paddle move only left and right, I though it would be more interesting and more fitting to the form factor to extend the movement on the whole bottom half of the screen, where the thumb of the player has the easiest reach.
The second choice was about the paddle itself, its form and behaviour: having the paddle always present on screen felt somehow wrong and static. I wanted to give a more tactile feeling, so that it’s almost like the thumb itself is the paddle. So I decided that the paddle would spawn only when the player touches the screen. Now that the thumb is the paddle, it was logical to give the paddle a curved shape, like a thumbnail.
A paddle that spawns only when the player touches the screen creates a new opportunity, as the timing of the spawn can be used in a creative way. I had an idea: by spawning the paddle one second before it hits the ball, the player can super charge the ball, and a supercharged ball will go through bricks instead of bouncing off them. This mechanic rewards timing and skilfulness and fits with the core idea of the game: simplicity. I wanted to ship a game quickly, and this meant that I had to try and limit the scope as much as possible. I also wanted to make a game that was simple to play and that would allow for extremely short sessions. The super mode activated by timing allowed me to avoid implementing bonuses: I briefly considered the idea of implementing multiball or other typical bonuses of this genre but it just didn’t feel they added much. It felt like something that would just add unnecessary systems.
I started, instead, to layer the super mode feature. At the most basic level, the mechanic already has an implicit risk/reward: instead of always keep touching the screen, the player can decide to risk missing the ball and touch the screen with the right timing to activate super mode, which in turn will give the player the reward of more bricks destroyed. On top of that I created another risk/reward mechanism: bricks destroyed by a ball in super mode will give twice the amount of points. However, every time super mode is activated, the minimum speed of the ball is slightly increased, permanently. This is an advantage in the beginning of the game, as the player can clean up a screen faster, but becomes progressively a handicap after the first couple of levels, when more speed means more risk of missing the ball.
After that core mechanic I wanted to implement a more subtle feature. I always felt a weak point of the Breakout/Arkanoid design is that once the ball bumps off the paddle, the player can do nothing but wait. The player also has limited control, as the angle of the ball determines where the ball will go. Inspired by the bending of Sensible Soccer (in which the player could bend a shot left or right by moving the joystick after a kick) I implemented a system where moving the paddle right after the ball bounced would bend the trajectory of the ball left or right. The effect had to be noticeable but subtle, so I chose to show it in a toned-down way, with a small dot rotating around the ball clockwise or anticlockwise depending on the direction of the bend.
It was now possible to direct the ball in a more active way, but I still wanted to tackle a couple of weak areas of the classic design. One of the most annoying problems of Breakout is that the game becomes frustrating when only one brick remains. Even using the bending mechanic, too much precision is required to get that one last brick. Also, losing by letting the ball fall down off the screen feels somehow too sudden. Even a game over shouldn’t be too frustrating. It became clear to me that this was an issue of control: as it often happens with player’s frustration, the issue had to do with a feeling of not being in control. And that’s where I got the idea of adding a new way to interact with the ball.
I created a pull mechanic. If the bottom half of the screen is where the player can have the ball bounce off the paddle (push), the top half can be the “pull side”. When the player touches the top half, a sort of black hole attracts the ball to the touch point. The pull mechanic felt good and finally allowed for more control after the ball hit the paddle. Of course, it was also insanely overpowered. The pull move had be balanced with a strong incentive to limit its use. Considering that part of the initial concept was to focus on short sessions, it made sense to have a time limit. I’m not generally a big fan of time limits in games, but I do feel that they have a place. In this case, especially, introducing a time limit fit the rest of the mechanics. For example, with a time limit it becomes even more important to use the super mode, as super mode allows the player to beat a level faster. More importantly, now I had a tool to balance against the pull mechanic. Using the pull by touching the top half of the screen now drains seconds really fast. A quick tap will lower the timer by a couple of seconds – an acceptable trade off when correcting the trajectory to destroy the last brick – but holding down can sensibly reduce the available time.
Once the timer was in place I had to find a way to give the player extra seconds. I decided to award seconds at completion of a level and when the player destroys some special bricks. To make things a little more interesting, time-awarding bricks give one second less each time the ball bounces off the paddle, thus giving an incentive to the player to try and destroy the special bricks as soon as possible. Finding the right amount of seconds to give and how many special bricks to show was then a simple process of testing and tuning until it felt hard but not punitive or stress inducing. Most of the other design-related choices had to do with tweaking physics, correcting edge cases and try to keep everything – from UI to graphics – as simple as possible without making it completely dry.
The game took almost a year to complete. It was made in my spare time and it was put on hold several times. However, I am pretty satisfied with the results: Breaking Brix is, in my opinion, a fun tiny score-based game to play in the time between two subway stops or while on the toilet, which is exactly what I tried to create. Using a proven design as a base on which new ideas can be built upon is an invaluable exercise.
Now, I just need to find a way to make Tetris better…