"By designing natively for different input methods, you can bring life to a completely new game design," writes Dandara dev João Brant in this Deep Dive into the game's unique movement system.
The Gamasutra Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.
Check out earlier installments, including creating comfortable UI for VR strategy game Skyworld, achieving seamless branching in Watch Dogs 2’s Invasion of Privacy missions, and creating the intricate level design of Dishonored 2's Clockwork Mansion.
Hello! I am João Brant. Alongside with Lucas Mattos, we founded Long Hat House. We met on a local computer science university, where we decided to pursue our dream of making games and started Long Hat House in 2014. We didn’t stop making games ever since. I hope we never do!
Lucas and I work mainly with programming and design! We worked on our latest and largest project Dandara for around 2 running years, together with the musician Thommaz Kauffman and the artist Victor Leão.
Dandara began as a mobile game. We wanted to convey quality, fast-paced action mechanics on the touch screen. In this text, I'll try to explain the train of thought that we went through while developing the control scheme in Dandara, and how it evolved later, for gamepads as well.
When the development started, we were on a very different position. We didn't have a publisher or any kind of financial assistance, neither we had much experience or a portfolio. Our goal was to make it into consoles, but self-publishing there wasn’t an option.
That made us look at mobile platforms in a unusual way: trying to create mechanics that made sense for mobile natively, designed from the ground up, instead of bringing gameplay from other platforms or recurring to the dominating market ideas. The platform is capable of so much more, but was generally neglected by (non casual) players and developers because of what the market had become.
In the middle of the project, Raw Fury joined and helped us focus full time on Dandara. But they also opened so many doors. We decided to try a scheme for gamepads, and then to change focus to the Nintendo Switch where it could accommodate both types of controllers. In the end we were supporting most of the other platforms (PC, PS4, Xbox, TVOs). That surely influenced the development of the game a lot during the last year!
“Touch Release” and “Swipes”
I don’t know how basic is this notion, but after making our first game, Magenta Arcade, we realized something about touch screens: both initiating and releasing a touch feels as tactile and immediate as pressing a button on the controller. And the swipe motion is really powerful - the same action can be started, given a direction, and then finalized with the same ease it started. It feels natural to the touch screen too, while using overplayed gamepad controllers wouldn’t.
Drawing of the first pitch of the game
The first pitch: Your character ignores gravity, and snaps to platforms, jumping in a straight line from one to the other, while attacking with projectiles. Platforms, on the bottom and top of the screen, would move towards something that would kill you (or out of the screen), so you can’t stand still for too long. Also, there would be an enemy fighting you in the center. That would (hopefully) generate a dance between the player and the enemy, to find the perfect position to keep alive or to get to the enemy's weak spots.
At first, we would try pointing and touching to move or attack, but finally decided to focus on swipes. At one side of the screen you aim your movement, at the other you aim your attacks. Releasing the finger would confirm the action. This way you could move and shoot quickly by using swipes, without constantly covering the screen with your thumbs too!
You would use the mobile phone sideways like a game controller. It also has a good side effect on the player: by requiring both hands and having to hold the device like this, we’re enforcing more focus and attention, which is a different mindset from casual games. So with Dandara, we felt like we had a pretty cool setting to start playing with.
Iterations
In the very beginning we didn’t have any story, it all came through the gameplay, and evolved with it. A lot changed as we started prototyping.
Back then, the character could walk by holding the swipe to a direction, but considering the angles, the player would always move a bit when trying to jump. So we tried a “dash”, instead of walk, sliding in the floor on the release of the swipe when its direction was pointed to the ground, but it was hard to get players’ intentions. Also, jumping to the opposite ground added so much kinetic value to the action and it was always so fast to move around that we removed the walking function altogether.
As the game’s design really enabled exploration on a mobile game, which felt novel, we left behind the fixed arena structure from the pitch level and embraced more complex and connected maps.
After we decided for only jumping, we tried leaving movement as free as possible. But letting the player aim and land everywhere proved itself to be a nightmare. Moving fast felt great! But the player had to be too careful to not “miss” a jump and end up “falling” out of the scene, killing the pace of the game. Also, jumping to unwanted places meant that the player would have to, often, jump back to “fix” the movement, on the risk of missing the jump again, which was frustrating.
It is instinctive to have a limit on how far you can jump, and it didn’t make sense for the player to be making leaps of faith out of the screen, so we limited the range of the jump and didn’t let jumps without valid landing positions. And to minimize the unwanted jumps, we tested adding platforms only in places of interest. That’s when we came up with the white target areas where you can jump.
This all enabled a great movement rhythm! Only sometimes broken by mistakenly aiming out of a white spot. Releasing the finger from the screen, for example, could suddenly change a bit of its direction. So jump helpers were implemented as well. First, we “saved” where the last valid aim position was, and that’s where the player would jump to.. and this avoided jumps being unintentionally canceled when releasing the touch.
How the game played in the beginning, 2 months into development
We went further to help the ease of consecutive swipes, and not only use the direction of the swipe, but its length as well: the more you pull away from the origin position, the wider the game would search for valid points with side raycasters. The idea is to minimize the complicated movement required from the player’s finger to change direction and find a jump spot, and make a moving decision easier.
How the search works, the more you pull the swipe, the more the raycasts open, like a flower. If a target is found, it doesn’t need to search anymore
Attacking also evolved a lot! Inspired by games like Contra, we started with the simplest weapon: a “machine gun” that would shoot non-stop to wherever you’re pointing with no range limit. And because we wanted to embrace speed and action, we added an auto-aim to enemies as well.
That's a general idea of an “easy miniboss”. Which is still in the final game!
In the end, it was too easy. The player could stay far away, and eliminate enemies even from outside of the screen, without risk. That went against the idea of action, and it didn’t encourage exploration. We updated it to a close ranged wide shotgun-like attack, without auto-aiming. An instant improvement! The close range encouraged players to jump into the battle forcing a dance with the enemies. It also added value to positioning and good aiming. A full hit close ranged would hit the enemy with many projectiles at once, causing a lot of damage!
Level Design
Without any references for levels for this game design, we had to come up with all the rules that would make a good play area in Dandara.
One of the worst phenomena that happens in our level design, is what we call a mini dead-end. It is a spot that, if you go there by missing a jump, you can’t keep moving towards the direction you intend without having to jump back, to the other direction. Whenever the player hits a mini dead-end, it's always frustrating. Piling up that kind of frustration multiple times leads to a bad experience overall and they should be avoided as much as possible.
Here are a few examples of dead-ends. The pink trail (after making a mistake) will most always feel like going backwards.
Other things also made exploration harder, for example: jumping almost alongside a wall feels uncomfortable, enemy position that leads to a temporary mini dead-end, camera triggers properties and positions not letting you see the grounds or enemies, and many others.
Some of these problems can seem obvious, but it took a long time until we started understanding their causes and formulas. Eliminating them became, then, a big restriction in each level room. We had to consider different direction intentions and pathways, and although it got easier as gathered experience, it took us a lot of time in the beginning, and we had to re-design entire levels because of how they played. Doing playtests also helped us a lot with that, but it only came later in development.
Creating and using all those rules while trying to make engaging levels, teaching mechanics and maintaining a cohesive player flow was a fun, tricky challenge!
Gamepad
In the middle of the development, we signed with Raw Fury for publishing Dandara and, soon after, they got us an opportunity to port the game for the Nintendo Switch and we started trying gamepad options for it.
The first thing we thought about was to directly port touch controls: one analog stick leaps and the other attacks. Pointing the stick to a direction was like starting a swipe and releasing it would be, as you can imagine, the release. This was bad, as releasing the stick wasn't as immediate as releasing the touch screen and the final direction could change violently when doing it. Also, confirming the action through buttons, but aiming to different directions with each analog was very hard and unintuitive, even with shoulder buttons.
We gave up the ability of aiming movement and attack at the same time, on the controller. Mapping buttons for each action and using only the left analog stick to aim for both. This still wasn't perfect, as each leap required a movement in the stick to prepare for another leap, which could get tiring in long sessions.
The solution was to mirror the leap direction vector if the player was aiming through the ground. That way when he completed a leap, the player wouldn't have to move the stick as it would be already pointing forward. So, at most cases you only need to aim in one direction and keep pressing the leap button whenever you hit the ground. This helper allowed moving so fast and fluidly, that it made us believe that gamepad could be comfortable and fun for Dandara.
Mirror example, the green crystal is the direction in the analog stick
We worried about the learning curve for the gamepad, it felt strange to play at the beginning. But as we played the game, playtested it, evolved it, showed in events, and with Raw Fury’s excitement about it, we gained a lot of confidence, and the Nintendo Switch slowly became our main target platform. Even better as it housed both forms of input.
We believe that, one key point here is to show how, by designing natively for different input methods, you can bring life to a completely new game design. And we hope that with Dandara, and the growing amount of premium games that are coming natively to mobile, we can give another look into these devices, and re-evaluate its potential as a very accessible platform.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
