Redesigning an Xbox Game for Mobile

Our team was to remake the Xbox 360 game Raskulls from 2010 for mobile devices. Raskulls was originally designed around a physical controller and large TV displays. Bringing the game to mobile required redesigning every interaction—from controls and navigation to feedback—while preserving the fast paced feel that made the original game enjoyable.

Our team was to remake the Xbox 360 game Raskulls from 2010 for mobile devices. Raskulls was originally designed around a physical controller and large TV displays. Bringing the game to mobile required redesigning every interaction—from controls and navigation to feedback—while preserving the fast paced feel that made the original game enjoyable.

Since this project is still in development, I am unable to showcase any screenshots of my work or the remake itself. However, here is a trailer of the original 2010 game:

Goal

Goal

Design touch first interactions that preserve the responsiveness and competitive feel of the original Xbox experience while remaining intuitive for new mobile players.

Key Contributions

Key Contributions

Created responsive interactions through visual, haptic, and audio feedback, helping players understand when actions were registered and making gameplay feel faster and more satisfying.

Designed customizable control layouts and accessibility-focused options that accommodated different play styles, hand sizes, and player preferences without sacrificing competitive responsiveness.

Simplified navigation across menus, matchmaking, and gameplay by designing predictable state transitions and clear system feedback, helping players stay oriented throughout the experience.

Unique Challenges and their Solutions

Unique Challenges and their Solutions

Unique Challenges and their Solutions

Raskulls was originally designed around physical controllers, large televisions, and players sitting several feet away from the screen. Simply shrinking the interface for mobile would make the experience frustrating and imprecise.

New Input

Unlike the original Xbox version, the mobile version relied entirely on touch controls. This required redesigning interactions around virtual joysticks and on screen buttons while maintaining the speed and precision expected in a competitive platformer.

Solution

  • Large touch targets

  • Input forgiveness

  • Feedback (visuals, haptics, audio)

Modern UI/UX

The original game was designed around 2010, before many modern mobile interaction patterns existed. Our goal wasn't simply to recreate the interface—it was to redesign it around modern usability expectations while preserving the original identity.

Solution

  • Modern navigation

  • Clear hierarchy

  • Reduced complexity

Screen Space

Mobile devices provide significantly less screen space than the TVs the original game was designed for, forcing us to prioritize the most essential information. We simplified the interface, made layouts responsive, and respected each platform's safe areas to reduce clutter.

Solution

  • Simplified layouts

  • Safe areas

  • Responsive UI across different devices

Controls

Controls

Controls

The controls of the game are a vital part of the user experience as they are the method through which users provide input. Since the game is a competitive game, the controls had to be so intuitive that the user would not have to think about them as that would distract them from the game itself. Movement and interactions should become automatic through consistent behavior. Here are the key interaction improvements I designed:

Room for Error

Since the players will not always be looking at the controls, I allowed room for error just in case they tapped a few pixels away from where the actual button was. I did this by making the collision box for the button (where it accepts touch input) bigger than the visuals of the button.

Furthermore, when the player accidentally presses on the empty space between two nearby buttons, I implemented logic to calculate which of the two buttons is closer to the actual location of the tap and have that button be pressed.

Button Properties

Early playtests revealed that jump and zap are the most frequently used buttons during gameplay. Therefore, I positioned them closest to the player's thumbs and made them bigger than the other buttons. I also added different button layout presets that players could choose from to accommodate different preferences.

Feedback

I provided feedback to buttons through haptics, visuals, audio, or by disabling buttons that can’t be used at a given moment (disabling the powerup button when the player has no powerups). This helps the user know when their input has registered.

Joystick Interaction

Unlike buttons, joysticks require continuous finger movement, making them much easier to lose during gameplay. I experimented with different drag distances and activation areas while making the joystick remain active when players move slightly outside its visual bounds. This lead to players not having to constantly correct their thumb position. Similar to the button layouts, I added different joystick presets to accommodate different preferences.

Room for Error

Since the players will not always be looking at the controls, I allowed room for error just in case they tapped a few pixels away from where the actual button was. I did this by making the collision box for the button (where it accepts touch input) bigger than the visuals of the button.

Furthermore, when the player accidentally presses on the empty space between two nearby buttons, I implemented logic to calculate which of the two buttons is closer to the actual location of the tap and have that button be pressed.

Button Properties

Early playtests revealed that jump and zap are the most frequently used buttons during gameplay. Therefore, I positioned them closest to the player's thumbs and made them bigger than the other buttons. I also added different button layout presets that players could choose from to accommodate different preferences.

Feedback

I provided feedback to buttons through haptics, visuals, audio, or by disabling buttons that can’t be used at a given moment (disabling the powerup button when the player has no powerups). This helps the user know when their input has registered.

Joystick Interaction

Unlike buttons, joysticks require continuous finger movement, making them much easier to lose during gameplay. I experimented with different drag distances and activation areas while making the joystick remain active when players move slightly outside its visual bounds. This lead to players not having to constantly correct their thumb position. Similar to the button layouts, I added different joystick presets to accommodate different preferences.

Room for Error

Since the players will not always be looking at the controls, I allowed room for error just in case they tapped a few pixels away from where the actual button was. I did this by making the collision box for the button (where it accepts touch input) bigger than the visuals of the button.

Furthermore, when the player accidentally presses on the empty space between two nearby buttons, I implemented logic to calculate which of the two buttons is closer to the actual location of the tap and have that button be pressed.

Button Properties

Early playtests revealed that jump and zap are the most frequently used buttons during gameplay. Therefore, I positioned them closest to the player's thumbs and made them bigger than the other buttons. I also added different button layout presets that players could choose from to accommodate different preferences.

Feedback

I provided feedback to buttons through haptics, visuals, audio, or by disabling buttons that can’t be used at a given moment (disabling the powerup button when the player has no powerups). This helps the user know when their input has registered.

Joystick Interaction

Unlike buttons, joysticks require continuous finger movement, making them much easier to lose during gameplay. I experimented with different drag distances and activation areas while making the joystick remain active when players move slightly outside its visual bounds. This lead to players not having to constantly correct their thumb position. Similar to the button layouts, I added different joystick presets to accommodate different preferences.

How I Designed Responsive Interactions

How I Designed Responsive Interactions

How I Designed Responsive Interactions

While working on the game, I found that players judged interactions less by whether they technically worked and more by how responsive they felt. A jump that is technically accurate can feel sluggish and a menu can be usable while still feeling frustrating. This led me to approach gameplay through a UX lens where every interaction should communicate clearly, respond immediately, and reinforce the player's expectations.


Good interaction design reduces uncertainty by clearly communicating when the system has registered input and what happened as a result. Therefore, as well as optimizing interactions so users can accomplish tasks efficiently and confidently, I made it so that the interactions are also satisfying, responsive, rewarding, and emotionally engaging.

Immediate Feedback

Every player action should generate an immediate response.
Instead of waiting for the final result, I layered feedback throughout the interaction using:


  • UI reactions

  • particles

  • camera shake

  • sound effects

  • animation anticipation

  • haptics

  • squash and stretch


These communicate that the system has acknowledged the player's input.

Visual Effects

Particles, animation timing, lighting, and camera movement help direct the player's attention toward important events. Rather than telling players where to look, I used visual hierarchy to naturally guide them.

Consistency/Timing

Every mechanic follows consistent rules. If the player jumps, attacks, or interacts, similar inputs always produce similar outcomes as consistency builds trust. When players trust the system, they spend less mental effort understanding controls and more enjoying the experience.


As for the input, milliseconds matter. Small reductions in input delay dramatically changed how satisfying interactions felt.
I learned that users often perceive responsiveness more strongly than objective performance metrics.

Measuring Success

Rather than asking whether a mechanic was functional technically, I evaluated whether players:

  • understood what happened

  • felt in control

  • completed actions without hesitation

  • repeated interactions because they were enjoyable

  • rarely questioned system behaviour


These observations became the primary criteria I used to evaluate whether an interaction felt successful.

Immediate Feedback

Every player action should generate an immediate response.
Instead of waiting for the final result, I layered feedback throughout the interaction using:


  • UI reactions

  • particles

  • camera shake

  • sound effects

  • animation anticipation

  • haptics

  • squash and stretch


These communicate that the system has acknowledged the player's input.

Consistency/Timing

Every mechanic follows consistent rules. If the player jumps, attacks, or interacts, similar inputs always produce similar outcomes as consistency builds trust. When players trust the system, they spend less mental effort understanding controls and more enjoying the experience.


As for the input, milliseconds matter. Small reductions in input delay dramatically changed how satisfying interactions felt.
I learned that users often perceive responsiveness more strongly than objective performance metrics.

Visual Effects

Particles, animation timing, lighting, and camera movement help direct the player's attention toward important events. Rather than telling players where to look, I used visual hierarchy to naturally guide them.

Measuring Success

Rather than asking whether a mechanic was functional technically, I evaluated whether players:

  • understood what happened

  • felt in control

  • completed actions without hesitation

  • repeated interactions because they were enjoyable

  • rarely questioned system behaviour


These observations became the primary criteria I used to evaluate whether an interaction felt successful.

Immediate Feedback

Every player action should generate an immediate response.
Instead of waiting for the final result, I layered feedback throughout the interaction using:


  • UI reactions

  • particles

  • camera shake

  • sound effects

  • animation anticipation

  • haptics

  • squash and stretch


These communicate that the system has acknowledged the player's input.

Consistency/Timing

Every mechanic follows consistent rules. If the player jumps, attacks, or interacts, similar inputs always produce similar outcomes as consistency builds trust. When players trust the system, they spend less mental effort understanding controls and more enjoying the experience.


As for the input, milliseconds matter. Small reductions in input delay dramatically changed how satisfying interactions felt.
I learned that users often perceive responsiveness more strongly than objective performance metrics.

Visual Effects

Particles, animation timing, lighting, and camera movement help direct the player's attention toward important events. Rather than telling players where to look, I used visual hierarchy to naturally guide them.

Measuring Success

Rather than asking whether a mechanic was functional technically, I evaluated whether players:

  • understood what happened

  • felt in control

  • completed actions without hesitation

  • repeated interactions because they were enjoyable

  • rarely questioned system behaviour


These observations became the primary criteria I used to evaluate whether an interaction felt successful.

User Flow

User Flow

User Flow

Challenge

The game contains multiple menus, and online multiplayer states, creating many possible navigation paths. Players needed to move between these states without becoming confused or losing context.

Solution

We designed navigation flows around player intent, ensuring transitions between menus, gameplay, matchmaking, and error states were predictable and easy to understand. Every screen communicated what was happening, why it was happening, and what the player should do next.

Examples

  • Clear error overlays for network and server issues.

  • Matchmaking and waiting state screens.

  • Countdown and lobby status updates.

  • Notifications when players disconnected mid match.

  • Consistent navigation patterns across all menus and game modes.

Key Learning Point

Key Learning Point

Key Learning Point

Designing responsive interactions taught me that perceived responsiveness often matters more than perfect technical accuracy.

Designing responsive interactions taught me that perceived responsiveness often matters more than perfect technical accuracy.