Fast-tracking game ideas: Inside our drag-and-drop design toolkit

In game development and spatial design, the gap between a great idea and a playable prototype is often paved with repetitive setup. To solve this, the design team at Magnopus created the Magnopus Design Toolkit (MDT). Built directly in Unreal Engine, MDT gave designers immediate access to standard UI components and basic actor behaviors engineered to turbocharge the prototyping phase.

As our project demands evolved, we set out to upgrade the system into MDT 2.0: a modular, drag-and-drop repository designed to empower creators to build higher-quality experiences, faster.

Here’s a look inside MDT 2.0, how we put it to the test with "Project Starblade," and what we learned along the way.

Building MDT 2.0: The drag-and-drop dream

The goal of MDT 2.0 was to build a repository of standard mechanics and blueprints to empower designers during prototyping. We wanted individual mechanics that could be easily dragged and dropped into projects, saving the time it normally takes to build these systems from scratch.

Over three months, our team developed 15 mechanics and systems, ranging from inventory management and dynamic item looting to overlapping world setups. We chose these based on their relevance to past Magnopus projects and their commonality in popular games.

To ensure quality, the team operated on a peer-review system. Designers researched, built, and then reviewed the tools together, evaluating them on time saved, adherence to original goals, and potential improvements.

Nodes in the Character Blueprint.

Testing the toolkit: Project Starblade

A toolkit is only as good as its practical application. To put MDT 2.0 through its paces, we launched Project Starblade, a training initiative designed to test both our new tools and our prototyping capabilities.

The team was split in half to tackle two distinct game proposals:

• Ninja Protectors: A stealth-action game in the vein of Assassin's Creed.

• Stardust: A simulator where you play as a modern influencer and pop star.

The swap methodology

To truly test our processes, we started with a one-week design and documentation phase. Teams were assessed on clarity, feasibility, toolkit utilization, and efficiency.

Then came the twist: the teams swapped projects.

Each team had three weeks to build a functional, playable MVP (Minimum Viable Product) prototype using the other team's documentation. This was the ultimate test of our design documentation skills and the usability of our new toolkit.

How did the tools perform?

The results of the three-week prototyping sprint were eye-opening and heavily dependent on the game's genre.

Successes and Challenges: 

Ninja Protectors
Serving as a favourable testing environment for MDT 2.0, Ninja Protectors demonstrated how the toolkit could be leveraged to add instant value:

• Overlapping worlds: This tool perfectly powered the game's Phase Shift ability, allowing players to dip into a parallel environment to sneak past enemies.

• Highlight objects: Easily adapted into a sonar-like pulse that revealed key environmental items.

• UI components: Pre-made widgets and On-Actor UI components quickly handled player health, shuriken ammo, and enemy detection statuses (floating icons indicating if an enemy had spotted the player).

Because the toolkit handled the foundational mechanics well, the team could expand on these and spend their time polishing the bespoke elements of the game, like enemy AI and combat mechanics.

Stardust

Stardust, while benefiting from time saved using the MDT 2.0, also highlighted some limitations of the toolset.

• Performance bottlenecks: The team attempted to use the Look At Player tool (designed to make standard Unreal mannequins face the user) at scale. However, the blueprints were not optimised for animating and calculating said logic for hundreds of NPCs, thereby affecting the game's performance.

• Lack of coverage: While the Equipping Items tool worked great for letting the pop star hold stage props, the vast majority of Stardust's unique social and performance mechanics simply weren't covered by the pre-packaged tool, forcing the team to build from scratch.

Overall, both teams were able to benefit from getting core gameplay mechanics such as locomotion, camera set-ups, item pickups and health bars, among many others, in place swiftly to reach a more viable product. The crucial learning here is that while planning the implementation of a design, one must think far enough ahead to anticipate the limitations of technical tools and take this into account.

Overall learnings

Project Starblade ultimately yielded fantastic, playable prototypes, but the real value was in the lessons we took away about tooling, documentation, and production design.

Time saved is polish earned: The biggest success of MDT 2.0 wasn't just speed; it was resource allocation. Teams didn't have to build health bars or basic gameplay logic, allowing them to channel their energy into complex, bespoke systems, leading to roughly 30% increased velocity compared to starting from scratch. Good tools don't just make development faster; they make the final product better.

The BP_HealthComponent decoupled logic from consequences, allowing designers to drop health tracking and dynamic UI widgets onto any actor instantly.

Scalability requires stress testing: A tool that works beautifully on a single NPC might break your game when applied to a crowd of 100. Our experience with Stardust proved that future tools must be stress-tested for scale and optimized for performance, even in the prototyping phase.

Genre bias in tool creation: MDT 2.0 leaned heavily into traditional action-adventure mechanics. Going forward, when building universal toolkits, we need to ensure we are covering a wider spectrum of interactions – including social, UI-heavy, and simulation mechanics – to support all types of projects.

Documentation is the ultimate dependency: Swapping game design documents halfway through the project proved that a tool is only as good as the instructions attached to it. Clear, visual, and feasible documentation is the glue that enables a team to actually leverage a shared toolkit effectively.

MDT 2.0 and Project Starblade successfully revived a culture of proactive skill-building at Magnopus. We now have a tangible library of assets to speed up our next pitches and prototypes, and more importantly, a clearer roadmap for future expansions of the toolkit, focused on performance optimization at scale, broader genre mechanics, and greater tool compatibility.