Dimension Shift: Racing Beyond Reality

A Research Paper on the Planning, Development, Prototyping, Market Validation, and Sustainability of an Original Arcade Racing Game

Ayush Saraogi — Team Lead | Nathan Wai Yan Moe Kyaw — Lead Programmer

Ashish Maharjan — Lead Designer | Linn — QA and User Experience Lead

Course: Game Design | Institution: Raffles International College

Project: Dimension Shift | Date: September 2026

Racing games have remained an important part of the video game industry because the main objective is easy to understand: control a vehicle, follow a track, and try to achieve the best result. Racing games can offer different experiences, from realistic driving simulations to fast arcade races with stunts, boosts, shortcuts, and unusual environments.

Research into existing racing games, including Asphalt 8, shows that speed, vehicle upgrades, stunts, route selection, and competition can make racing enjoyable. However, unclear upgrade systems, difficult menus, uncertain rewards, and unfair competition may create frustration for players. These observations show why a racing game needs both enjoyable driving and clear supporting systems.

Dimension Shift is an original arcade racing concept developed around the idea of racing across different realities. During a race, players can shift between dimensions to discover alternate routes, avoid hazards, or improve their position. A futuristic city may change into a broken world filled with floating roads, energy fields, and unstable structures. The player must decide when to shift and which dimension offers the best route.

Dimension Shift is not intended to copy Asphalt 8 or another existing racing franchise. The identity of Dimension Shift will come from its original vehicles, environments, track design, visual style, and dimensional- shifting mechanic.

The main research question is:

How can a small game-development team plan, develop, prototype, and evaluate an original arcade racing game that uses dimensional shifting as its main gameplay feature while remaining technically practical and commercially sustainable?

The paper also examines the following questions:

• What gameplay systems should be included in the first prototype?
• What research and planning are needed before production begins?
• What creative, technical, financial, and team-related problems may occur?
• How can player testing help the team improve Dimension Shift?
• What steps may help Dimension Shift find a place in the gaming industry?

Game title: Dimension Shift Genre: Futuristic arcade racing Main experience: High-speed racing combined with dimensional shifting. Proposed platform: PC for the first prototype, with possible future development for consoles or mobile devices. Proposed engine: Unreal Engine 5. Target audience: Players who enjoy arcade racing, futuristic environments, time trials, vehicle customization, and new racing mechanics.

The main design idea behind Dimension Shift is simple: every race takes place across more than one reality. Players must control speed, steering, drifting, boost, and route selection while deciding when to change dimensions.

The visual style will use a futuristic neon setting with dark environments and strong blue, cyan, magenta, and violet lighting. The game may include glowing sports cars, digital signs, energy portals, futuristic buildings, and unusual landscapes. The final vehicles, environments, logos, and other assets will be designed or legally sourced for Dimension Shift.

The main feature of Dimension Shift is the ability to move between different versions of a racing environment. The first prototype will focus on two dimensions.

Dimension A: Neon City Neon City is a futuristic urban environment with elevated roads, digital billboards, tunnels, traffic barriers, sharp turns, and high-speed streets.

Dimension B: Rift World Rift World is an alternate reality with broken buildings, floating roads, energy fields, unusual gravity zones, and dangerous environmental obstacles.

A race may begin in Neon City and continue through a portal into Rift World. In some areas, players may have the choice to shift dimensions and select a different route.

Dimensional shifting should change the way a race is played. A shift may affect:

• The racing line.
• The position of obstacles.
• The safest route.
• The location of ramps and shortcuts.
• Environmental hazards.
• The appearance and atmosphere of the track.
• The risk and reward of a route.

The dimensional-shifting mechanic should not become only a button press. Players should receive enough information to make a useful decision. A successful shift may save time, while a poor decision may lead to a collision, a longer route, or a loss of speed.

The proposed gameplay loop for Dimension Shift is: Observe the track → Accelerate → Steer and drift → Manage boost → Study the route → Shift dimensions → Avoid hazards → Cross the finish line → Review the result → Improve the next attempt.

This loop combines driving skill with route decisions. Players must learn how to control a vehicle and when to change dimensions.

The first prototype will include acceleration, steering, braking, drifting, boost, collision detection, checkpoints, a finish line, and one working dimensional-shift interaction. Advanced features such as detailed vehicle damage, online multiplayer, large-scale customization, and complex physics will be considered later.

The main objective is to complete the race in the shortest possible time. Additional objectives may include:

• Completing a race without crashing.
• Choosing the correct dimension at key points.
• Performing a successful drift.
• Completing a shortcut.
• Beating a personal-best time.
• Defeating an AI opponent.
• Collecting optional energy fragments.
• Unlocking fictional vehicle designs.

These objectives can encourage players to repeat races and improve their results without requiring a large amount of content during the early development stage.

Before production begins, the team must study how existing racing games create enjoyment and keep players interested. Research should focus on driving controls, track design, speed, boost systems, progression, menus, rewards, and competition.

The Asphalt 8 research provides useful areas for investigation, including arcade driving, stunts, vehicle progression, economy, interface clarity, and player feedback. However, individual player complaints should be treated as research findings that need further investigation rather than proof of a problem affecting every player.

The team should study other racing games to understand their systems instead of copying their content.

• Asphalt 8: Useful for studying arcade speed, aerial stunts, boost management, vehicle progression, and the connection between racing and menus.
• Mario Kart 8 Deluxe: Useful for studying beginner-friendly controls and ways to help new players enter the game. Dimension Shift should not copy its racing systems because the two games have different designs.
• Trackmania: Useful for studying time trials, personal-best ghosts, route learning, and repeated attempts to improve racing performance.
• Forza Motorsport: Useful for studying vehicle progression and how player feedback may influence access to upgrades. This example should be treated as a case study rather than proof that every change will succeed.

The research suggests four design principles for Dimension Shift:

1. Make basic driving easy to learn.
2. Give players clear feedback about speed, time, and improvement.
3. Make dimensional decisions understandable.
4. Reward skill, route knowledge, and practice.

Not all racing players want the same experience. Some players prefer realistic driving, while others enjoy quick races, stunts, and simple controls. Some players prefer solo time trials, while others prefer competition with friends or online players.

The first target audience for Dimension Shift should be players who enjoy arcade racing, futuristic worlds, time trials, and unusual track mechanics.

The team should conduct a small survey or interview study with potential players. Questions may include:

• Would players understand a track that changes between dimensions?
• Would players prefer a short repeatable race or a long racing event?
• What makes players stop playing a racing game?
• What would encourage players to try a new racing game?
• How important are speed, drifting, shortcuts, and vehicle customization?

The answers should help guide the design. The team should record both positive and negative feedback rather than collecting only opinions that support the original idea.

Dimension Shift will enter a market that already includes well-known arcade racers, realistic racing games, and independent experimental titles. Attractive cars and neon graphics alone may not be enough to make Dimension Shift different from other games.

The main point of difference is the ability to race across alternate realities and make route decisions through dimensional shifting. The mechanic must change the race in a meaningful way. If shifting only changes the background, the feature will not give players a strong reason to play Dimension Shift.

The team should compare Dimension Shift with other racing games using the following design factors:

Pre-production is the stage where the team turns the game idea into a clear development plan. The first task is to create a Game Design Document (GDD).

The GDD should explain the purpose of Dimension Shift, the genre, target audience, gameplay mechanics, controls, camera, art direction, technical needs, progression, and project limits.

The team should also prepare a one-page concept sheet containing the game title, logo, genre, gameplay summary, target platform, main mechanic, visual references, and a short description of the player experience.

One important question must be answered before detailed production begins: What makes Dimension Shift enjoyable when the player is not shifting dimensions?

The answer should include responsive vehicle controls, satisfying driving, readable tracks, useful boost systems, and meaningful competition. Dimensional shifting should improve the racing experience rather than cover up weak driving controls.

A major risk in student and independent game development is trying to create too much content. A complete commercial racing game may need many vehicles, tracks, environments, menus, sounds, animations, online systems, testing, marketing, and technical support.

The first Dimension Shift prototype should therefore be a small vertical slice.

Proposed prototype scope:

• One original racing track.
• Two connected dimensions.
• One playable fictional vehicle.
• Basic acceleration, steering, braking, drifting, and boost.
• One working dimensional-shift mechanic.
• One AI opponent or personal-best ghost.
• A start screen, race screen, and results screen.
• Basic sound, visual effects, and interface feedback.
• A playable build for controlled testing.

These are project decisions made by the team. They are not established industry standards or facts about Asphalt 8.

Clear responsibilities will help the team complete the project on time. Team members should also support one another when a task requires more than one skill.

• Ayush Saraogi — Team Lead: Coordinates the project, manages the overall direction, tracks progress, supports art production, and helps maintain the project plan.
• Nathan Wai Yan Moe Kyaw — Lead Programmer: Develops vehicle controls, racing systems, checkpoints, collisions, dimensional shifting, and technical features.
• Ashish Maharjan — Lead Designer: Defines gameplay rules, track layouts, objectives, player flow, and game balance.
• Linn — QA and User Experience Lead: Organizes playtests, records player feedback, checks usability, tracks bugs, and helps improve the interface and player experience.

The team may share responsibilities during a student project. However, every task should have a clear owner.

The following 12-week plan provides a starting point for development:

The schedule should be adjusted according to team size, experience, hardware, and academic deadlines.

Unreal Engine 5 is a suitable candidate for Dimension Shift because the engine supports real-time 3D environments, vehicle gameplay, lighting, materials, animation, and performance testing.

Before creating detailed environments, the team should complete a small technical test. The test should confirm that the team can:

• Create a basic vehicle.
• Build a simple racing track.
• Add checkpoints and a finish line.
• Switch between two track states or dimensions.
• Record a race time.
• Run the project on the target computer.

A successful technical test can reduce the risk of discovering major problems after weeks of asset production.

The first vehicle should be designed for arcade racing rather than realistic simulation. The team must decide how acceleration, top speed, steering, braking, drifting, boost, turning, and collisions will work.

The vehicle may be a futuristic sports car with a clear and recognizable shape. Vehicle production can begin with concept sketches, blockout modeling, topology refinement, UV layout, texturing, materials, lighting, and in-engine testing.

The vehicle should feel responsive before the team spends time on small details. A simple vehicle that handles well is more useful for the first prototype than a highly detailed vehicle that is difficult to control.

The first track should demonstrate the dimensional-shifting mechanic. The track may begin in Neon City, pass through a portal, and continue into Rift World.

The track should include:

• A clear starting line.
• A readable racing route.
• A small number of turns.
• One drift section.
• One boost section.
• A dimensional-shift zone.
• One alternate route.
• Visible hazards.
• A finish line.

The two dimensions should share enough of the route structure for players to understand how the world changes. The differences may come from lighting, architecture, materials, sky treatment, particles, and track hazards.

Level design should focus on visibility. If players cannot see the route or understand the result of a shift, the problem may be unclear communication rather than a useful gameplay challenge.

The interface should provide the information needed during a race. The HUD may include:

• Speed.
• Current position.
• Boost meter.
• Race timer.
• Checkpoint or route indicator.
• Shift availability.
• A warning for dimensional changes.
• A clear results screen.

After a race, players should be able to see the race time, personal-best time, crashes, successful shifts, and completed objectives. This information can help players understand how to improve.

Sound should communicate speed and actions. Dimension Shift may include engine sounds, boost activation, tire friction, collisions, checkpoint audio, ambient effects, and a recognizable dimensional-shift sound.

The shift effect may use portal animation, brief distortion, particles, lighting changes, or a change in the environment. Effects should remain clear enough for players to see the track. Excessive bloom, screen shake, or motion blur may make driving difficult.

A prototype is a playable version of a game used to test whether the main idea works. A prototype does not need the quality or amount of content expected from a commercial release.

For Dimension Shift, the prototype should answer the following question: Does shifting between dimensions make racing more interesting, understandable, and replayable?

The prototype should provide evidence about the quality of the mechanic, the player experience, and the technical requirements. The prototype should not be presented as proof that Dimension Shift will become commercially successful.

Stage 1: Paper and visual prototype The team creates track diagrams, route maps, vehicle sketches, interface layouts, and dimensional-transition storyboards. This stage helps identify unnecessary features before programming begins.

Stage 2: Graybox prototype The track is built using simple shapes. A placeholder vehicle is used to test speed, steering, drifting, checkpoints, and track layout.

Stage 3: Mechanic prototype The dimensional-shifting mechanic is added. The team checks whether players can understand when shifting is possible, what changes after shifting, and how the decision affects the race.

Stage 4: Vertical slice The prototype receives vehicle art, environment assets, materials, lighting, sound, visual effects, and interface design.

Stage 5: Playtest Players who were not involved in development try the game. Their actions, comments, confusion, failures, and preferences are recorded.

The team should recruit testers with different levels of racing-game experience. Each tester should receive the same instructions and the same prototype build.

Possible testing tasks include:

• Complete a driving tutorial.
• Finish the race.
• Identify when dimensional shifting is available.
• Explain what changes after shifting.
• Choose between two routes.
• Complete a race attempt and compare the result.
• Explain whether dimensional shifting affected the racing experience.

The team can record completion rates, time taken, accidental inputs, crashes, successful shifts, and player explanations. Comments should be kept with the observations so that the team can understand why a problem occurred.

The following are project-defined acceptance targets:

• At least four out of five testers can complete the basic tutorial without direct assistance.
• At least four out of five testers can explain the purpose of dimensional shifting.
• Most testers can identify the main route after a shift.
• Testers can complete the basic race without a game-breaking bug.
• The prototype can run on the selected target computer.
• The team records and reviews all major feedback.

These targets are proposed design goals, not proven industry benchmarks. The actual results must be reported honestly after testing.

After the vertical slice becomes stable, the team can prepare a market-facing prototype package containing:

• Game logo and key art.
• A short gameplay trailer.
• Gameplay screenshots showing both dimensions.
• A short game description.
• A playable demo.
• A developer introduction.
• A feedback form.
• A basic presentation or store-page draft.

The first market objective should be to discover whether players understand the concept and want to experience Dimension Shift. Social-media views and likes should not be treated as proof of commercial success.

A small student team may have limited funding, hardware, programming experience, and production time. Academic deadlines and other responsibilities may also affect development.

The team should reduce the scope, divide work into milestones, focus on the core mechanic, and avoid building systems that cannot be tested during the project period.

Racing games need responsive controls. Large environments, high-resolution textures, complex materials, lighting, particles, physics, and several vehicles may reduce performance.

The team should measure frame rate, frame time, CPU use, GPU use, memory, draw calls, texture memory, post-processing, collision complexity, asset loading, level-of-detail settings, and performance during dimensional transitions.

Optimization should begin early enough for the team to reduce unnecessary detail without damaging the visual identity of Dimension Shift.

The dimensional-shifting mechanic may create problems with collision, camera movement, physics, route continuity, checkpoint placement, and player direction.

A practical solution for the first prototype is to use controlled transition zones. The player enters a portal, the game performs a transition, and the vehicle appears on a tested route in the alternate dimension. This method may be easier to build and debug than a fully changing world.

If one dimension is always faster, players may ignore the other dimension. If shifting is too difficult, players may avoid the mechanic. If shifting is too powerful, other racing skills may become less important.

The team should test shift timing, energy cost, route length, hazard placement, boost availability, visual warnings, and recovery after a failed shift. Balance should be based on repeated testing rather than personal assumptions.

Possible bugs include vehicles passing through barriers, missing checkpoints, broken portals, camera clipping, incorrect timers, inconsistent collisions, and crashes during transitions.

The team should maintain a bug tracker with the bug number, description, steps to reproduce, severity, build version, assigned developer, current status, and verification result.

Clear communication is also important. A shared task board, organized folders, agreed naming rules, version control, and regular meetings can reduce duplicated work and missing assets.

Dimension Shift must remain an original project. Existing racing games may be studied for research, but their logos, names, vehicle models, characters, music, environments, and proprietary assets should not be copied into the final product.

The team should use original or properly licensed vehicles, tracks, software, sound, music, and other assets.

Survival in the gaming industry requires careful planning, useful feedback, and the ability to respond to changing technology, player expectations, costs, and competition. A studio should not spend all its resources on a large game before testing whether the main idea is useful.

The team should prepare a simple financial plan that includes software, hardware, salaries or contractor costs, asset production, music licensing, marketing, platform fees, testing, support, and emergency expenses.

Possible business models include:

• Premium purchase: Players pay once to access the game.
• Free demo with a paid game: Players try a short version before deciding whether to purchase.
• Early Access: Players buy an unfinished but playable version and provide feedback during development.

The business model should match the size of the game, its audience, development costs, and chosen platform. The student prototype should not include real-money purchases.

Dimension Shift needs a clear identity that connects the visual style with the gameplay. The identity may come from dimensional shifting, original vehicle designs, futuristic lighting, a recognizable logo, and a clear game message.

The team can begin community development during prototyping by sharing environment artwork, modeling progress, short gameplay clips, development updates, and controlled demo tests.

The purpose should be to gather useful feedback and build interest. The team should avoid promising release dates or features that have not been confirmed.

After launch, the team should track bugs, player feedback, performance, and development costs. Sustainable development means keeping the scope manageable, documenting systems, protecting the team from burnout, testing features before release, and communicating honestly with players.

A successful prototype may lead to a larger game, but a prototype alone cannot prove market demand or commercial success. The team must continue learning from player feedback and measure whether new content is worth its production cost.

The main contribution of Dimension Shift is a documented process for turning an original racing-game idea into a playable prototype. The project combines game design, environment art, programming, technical testing, player research, and market planning.

The research should produce:

• An original racing concept.
• A documented game design and production plan.
• A playable prototype.
• A working dimensional-shifting mechanic.
• A tested racing track.
• Evidence of player understanding and feedback.
• A record of development problems and solutions.
• A future development roadmap.
• A prototype presentation package.

The team should not claim that Dimension Shift is commercially successful or that all players prefer the mechanic without supporting evidence. The research should instead report the actual findings and explain what the team learned.

Dimension Shift is proposed as an original arcade racing game that combines futuristic driving with a dimensional-shifting mechanic. The main design goal is to make the choice of reality an important part of the race rather than a simple visual change.

Developing Dimension Shift requires a clear process beginning with research, concept development, scope definition, and technical testing. Production should then move through vehicle creation, track design, programming, dimensional transitions, interface design, sound, lighting, and playtesting.

The project may face challenges involving performance, collisions, game balance, team communication, limited resources, competition, and market awareness. These problems can be reduced through controlled scope, early testing, proper documentation, and decisions based on evidence.

Surviving in the gaming industry requires more than creating a game. A project needs a clear identity, enjoyable gameplay, a realistic financial plan, good teamwork, and a willingness to improve through feedback. Dimension Shift should therefore begin as a focused and testable project.

The next step is to build one playable track, two dimensions, one fictional vehicle, and a working dimensional-shift mechanic. After the core experience has been tested, the team can decide whether Dimension Shift should grow into a larger commercial game.

Epic Games. (n.d.-a). Introduction to performance profiling and configuration in Unreal Engine. Epic Developer Community.

Epic Games. (n.d.-b). Optimizing and debugging projects for real-time rendering in Unreal Engine. Epic Developer Community.

Gameloft. (n.d.-b). Customer care: Asphalt 8 [Legacy FAQ]. Asphalt 8 support information.

Nintendo. (n.d.). Beginner basics for Mario Kart 8 Deluxe: Techniques for getting the lead on your rivals. Mario Kart 8 Deluxe beginner guide.

Research pack. (2026, September 9). Redesigning an arcade racing game through Asphalt 8 research [Unpublished course research document].

Turn 10 Studios. (2024, May 9). A message to the Motorsport community—May 2024. Forza. Forza Motorsport community update.

Ubisoft Nadeo. (n.d.). Welcome to the club: Trackmania access comparison. Trackmania access comparison.

Unity. (2026, March 9). 2026 Unity game development report: How studios are building a future. Unity game development report.

Valve. (n.d.-a). Coming soon. Steamworks Documentation. Steamworks Coming Soon documentation.

Valve. (n.d.-b). Release options. Steamworks Documentation. Steamworks release options.

Valve. (n.d.-c). Wishlists. Steamworks Documentation. Steamworks wishlist documentation.

1. Finalize the Dimension Shift game concept.
2. Complete the Game Design Document.
3. Define the target platform and hardware.
4. Create original vehicle concept art.
5. Block out the racing track.
6. Implement vehicle controls.
7. Implement acceleration, braking, and drifting.
8. Add boost or nitro.
9. Create two track states.
10. Implement the dimensional-shifting mechanic.
11. Add checkpoints and a finish line.
12. Create HUD and results screens.
13. Add visual effects and dimensional-transition effects.
14. Test camera behavior.
15. Profile performance on target hardware.
16. Conduct playtests.
17. Record player feedback.
18. Revise the prototype.
19. Prepare gameplay screenshots and a trailer.
20. Present the prototype and future market plan.

Research → Identify player needs → Define design requirements → Create solutions → Build prototype → Test with players → Analyze observations → Revise the design → Evaluate feasibility → Plan future development.