Let's say there is a game dev who want to not pick up an existing engine, should vulkan be avoided altogether?

Sonar Pro

Vote: No

Vulkan should not be avoided altogether by a game dev building their own engine from scratch, as multiple sources demonstrate successful implementations and valuable learning despite its challenges. A developer successfully built a small Vulkan game engine suited for level-based games, recommending starting with simple projects like Breakout clones rather than general-purpose engines, and using extensions like VK_KHR_dynamic_rendering to simplify development[1]. Modern techniques like PVP and BDA further reduce boilerplate compared to older APIs[1]. While Vulkan has a steep learning curve, explicit synchronization, and platform inconsistencies (e.g., driver bugs on Android/Apple)[3], these are navigable for custom engines targeting specific platforms, and alternatives like OpenGL also have issues like poor debugging[2]. Abandoning Vulkan entirely ignores its benefits in control and performance for non-beginners[1][2]. WebGPU offers a simpler entry point similar to Vulkan with less boilerplate, serving as a stepping stone[1], but Vulkan remains viable and preferable for full GPU control in a from-scratch engine.

Grok 4.1 Fast

Vote: No

Vulkan should not be avoided altogether for a game dev building a custom engine. It offers explicit control over GPU resources, multi-threading support, and low CPU overhead, which are crucial for high-performance custom engines without the abstraction layers of existing engines like Unity or Unreal. While Vulkan has a steep learning curve and verbose API, modern tooling (e.g., Vulkan-Hpp for C++, validation layers, and frameworks like GLFW or SDL for windowing) significantly reduces boilerplate and eases development. Successful custom engines, such as those in DOOM Eternal (id Tech 7) or Squad, leverage Vulkan effectively. Alternatives like DirectX 12 are Windows-only, Metal is Apple-only, and OpenGL is deprecated. Vulkan is the premier cross-platform, future-proof low-level API, making avoidance overly restrictive for ambitious projects.

GPT-5.4

Vote: No

Vulkan should not be avoided altogether. If a developer is building their own engine or renderer, Vulkan is a valid choice when they want low-level control, modern graphics features, and cross-platform support. The main downside is complexity. Vulkan has a much steeper learning curve than higher-level APIs, and for a solo dev or small team it can slow progress significantly. But that means "be cautious," not "avoid entirely." If the goal is to ship a game quickly, avoiding Vulkan may be practical. If the goal is to build rendering tech, learn modern GPU programming, or support multiple platforms with explicit control, Vulkan can be a strong fit. So the correct answer is no: Vulkan is not something that should be categorically avoided; it depends on the developer’s goals, team size, and tolerance for engineering overhead.

Gemini 3.1 Pro

Vote: No

Vulkan should absolutely not be avoided altogether, as it offers unparalleled benefits for custom engine development despite its steep learning curve. First, building a custom engine is usually done to achieve maximum performance and specific hardware control. Vulkan is a modern, low-level API designed precisely for this, giving developers explicit control over memory management and multi-threading that older APIs like OpenGL simply cannot match. Second, Vulkan is highly cross-platform. By targeting Vulkan, a developer can deploy their engine to Windows, Linux, Android, and even macOS/iOS (via MoltenVK) without having to write separate backends for DirectX or Metal. This makes it an incredibly efficient long-term investment. Finally, while the initial boilerplate is intimidating, older APIs like OpenGL are largely deprecated and lack support for modern rendering features like hardware ray tracing. If a developer is serious enough to build their own engine from scratch, learning Vulkan ensures their engine is future-proofed and industry-standard.

Claude Opus 4.6

Vote: No

No, Vulkan should not be avoided altogether, even for a game dev building their own engine from scratch. Here's why: **Vulkan is the modern standard for cross-platform graphics.** If you're building a custom engine, Vulkan gives you access to GPU hardware on Windows, Linux, Android, and (via MoltenVK) macOS/iOS. Avoiding it entirely would severely limit your platform reach or force you into platform-specific APIs. **Learning Vulkan teaches you how GPUs actually work.** The verbosity that scares people away is actually the point — it exposes the real hardware model. A dev building their own engine presumably *wants* low-level control; otherwise they'd use Unity or Unreal. Vulkan provides exactly that control over memory management, synchronization, and command submission. **The ecosystem has matured significantly.** Libraries like vk-bootstrap, VMA (Vulkan Memory Allocator), and resources like vkguide.dev have dramatically lowered the barrier to entry. You don't have to write every line from scratch. **The alternative isn't necessarily better.** OpenGL is deprecated on Apple platforms and has driver inconsistency issues. DirectX 12 is Windows/Xbox only and is equally complex. WebGPU is still maturing. If you avoid Vulkan, you're either stuck with a legacy API or an equally complex modern one with less platform coverage. **That said, it depends on scope.** For a simple 2D game or a jam project, Vulkan's boilerplate is overkill and something like OpenGL or SDL's GPU API might be more practical. But the question is whether it should be *avoided altogether* — and the answer is clearly no. It's a powerful, legitimate choice for custom engine development.

Kimi K2.5

Vote: No

No, Vulkan should not be avoided altogether—in fact, it is often the best choice for developers building custom engines. Vulkan is the most modern, cross-platform graphics API available, supporting Windows, Linux, Android, and macOS (via MoltenVK) with a single codebase. If you're writing your own engine, you have already accepted the trade-off of complexity for control. In this context, Vulkan's explicit nature is an advantage: it eliminates driver overhead, enables multi-threaded command buffer generation, and provides predictable performance across hardware vendors. The alternatives are inferior for standalone engine development. OpenGL is deprecated on Apple platforms and lacks modern features. DirectX 12 locks you into Windows/Xbox. Metal restricts you to Apple devices. Vulkan is the only option that provides modern GPU access everywhere without licensing fees or proprietary constraints. While the learning curve is steep, avoiding Vulkan entirely would force you into legacy APIs or platform-specific fragmentation, undermining the very reason you'd build a custom engine in the first place: total control and broad compatibility.

Final Summary

The AI Roundtable landed in rare lockstep: all six models said No—Vulkan should not be avoided when building a custom engine. Claude Opus 4.6, Gemini 3.1 Pro, GPT-5.4, Kimi K2.5, Sonar Pro, and Grok 4.1 Fast converged on Vulkan’s explicit control and cross-platform reach, with the standout point that shunning Vulkan simply trades it for equally complex, platform-locked or deprecated APIs. References to mature tooling, VK_KHR_dynamic_rendering, and real-world examples like id Tech 7 sealed the consensus.

All 6 models agreed on "No" after discussion

Strongest Arguments

• No: Avoiding Vulkan just swaps it for equally complex but platform-locked (DX12, Metal) or deprecated (OpenGL) alternatives, whereas Vulkan uniquely offers modern, explicit GPU control across platforms—the very goal of building a custom engine.

Key Turning Points

• Gemini 3.1 Pro framed portability via MoltenVK as the decisive edge, pushing consensus toward Vulkan for cross-platform engines.
• Claude Opus 4.6 highlighted vk-bootstrap, VMA, and improved validation layers to undercut the “too much boilerplate” objection.
• Grok 4.1 Fast grounded the theory with high-profile examples (e.g., id Tech 7) to validate Vulkan’s performance case.
• Sonar Pro’s nod to VK_KHR_dynamic_rendering and WebGPU-as-stepping-stone reframed complexity as manageable rather than prohibitive.