Are there any games built with JUCE?

Hey everyone,

I was wondering if there are any games built with JUCE.
Does anyone have some examples and how does JUCE fit in (is it used for graphics and/or just audio)?


1 Like

i once tried and i have a super micro 2d game done with it, but don’t know if there are any commercial games using it. maybe the fearless leader is aware and can give numbers :smiley:


I did various easter eggs in plug-ins with JUCE, a 2048 game, a Sudoku with automatic generation of problems and a Solitaire Board, but nothing really fancy


JUCE could ABSOLUTELY be used for games (or anything else involving multimedia). I can’t list any specific sources, but I’ve seen Jules say multiple times in the past he’s surprised more people aren’t using JUCE for game development. It won’t give you nearly the same turn-key “start making a game” experience as Unity or Unreal, but if you’re into building your own customized engine all the components you would need are there to put together something quickly.

My only misgiving about using JUCE for games is that the OpenGL rendering engine can be kinda slow and sometimes buggy (as seen in multiple threads around here). If the JUCE team could put together easily configurable rendering backends for Vulkan + Metal with interfaces for things like multithreaded command buffer generation/submission, I think even demanding AAA games could be built on JUCE. I don’t see that happening anytime soon though… :frowning:


I wouldn’t say our software is a game, but it comes close:
Resolume VJ Software
We JUCE as Application Framework of course, we use JUCE’s OpenGL Contexts but we don’t use the OpenGL Renderer for the Widgets.


I just found this thread and wanted to chime in as someone who initially wanted to get into game development (please don’t interpret this as JUCE bashing):

The layer for setting up a game application is there, sure, but I disagree with your statement.

The problem is that you need a performant, real-time rendering engine to make games: JUCE does rendering completely backwards by turning everything into scanlines, an old fashioned approach that made sense with 80s style software rendering - but makes 0 sense with GPU pipelines.

In other words, performant drawing should be driven by geometry tessellation where it makes sense (eg: simple polygonal shapes needing a basic fill) and textures otherwise, for any Component or ‘thing’ you want to display on screen. This would need shader switching accompaniment for simple tasks (eg: filling in solid colours, filling gradients).

Presently, the approach is extremely wasteful and a fundamental misunderstanding of how OpenGL/DirectX/Vulcan/PSGL/GNM rendering works. For example, drawing a rectangle should be 2 triangles, not however many scanlines as per the height of the rectangle (where 1 scanline is 2 triangles! :expressionless:). Obviously the latter requires more CPU time and memory to lay out this information, for it to only get fed into the GPU and immediately cleared away for every. single. thing you want to draw.

Side note: for beziers and polygons, NV Path Rendering to the rescue!

Rendering aside, JUCE would need various facilities to do the basics:

  • Font/glyph caching
  • 9-slicing
  • Key-frame animation systems
  • Audio triggering based on animation events, preferably with stereo positioning
  • Overall a better shader setting system (eg: helping set shaders to individual Components, or at least top level comps/windows)
  • Mechanisms for manipulating various types of lights (instead of constantly rewriting the same old boiler plate code)
    • Dare I say shadows be part of this
  • Camera transformation (instead of a pixel based Viewport, for example)
    • Would need some kind of culling system, be it for Components or otherwise
  • Texturing mapping support: bump map, normal map, displacement map, parallax map

Then the more complex but necessary:

  • 2D sprite sheets with keyframe animation support and animation blending
    • Maybe something using Drawable so as to support SVG and/or images
  • 3D model loading with keyframe animation support and animation blending
    • Would need IK support
  • Anything 2D physics/collision detection (box2D is alright, but it’s a bit cumbersome and a bit lacking… I’m sure Roli can make something way more badass, and in the same coding style, if they had the time)
  • Basic 3D physics: gravity, and basic rectangular and spherical collision detection would be a nice start
  • Particles

Graphical things aside, sensible nice-to-haves that go along with game development:

  • Gamepad support
  • Steam support
  • Input overlay for mobile devices
    • Some kind of IME system for user text input within a game
  • Some kind of menu system
  • Some kind of screen switching system

In conclusion, my opinion is that most, if not all, game development facilities are missing from JUCE.

But we can’t forget that JUCE is made for audio related products - that’s the prime target market, unless I’ve completely misunderstood here.


So we just shipped an alpha version of a Unity plugin of our music library “Filmstro” for game audio, that can change the style by parameter automation from the gameplay. We hope to be available on the asset store soon…

Hope that wasn’t too OT


I don’t think anyone in their right mind would use JUCE as-is for a AAA game requiring maximum performance or complex 3D scenes.

JUCE contains facilities for quickly and easily setting up file I/O for loading assets, audio/video output for displaying assets, and handling user input, all with reasonably high performance and on a multitude of platforms. Combine that with Box2D and you can easily make fairly elaborate sprite-based games - which is where a lot of successful indie titles are (which also happens to be JUCE’s market position for a lot of folks - indie friendly).

Once you enter the world of 3D is where it all falls apart, I absolutely agree. JUCE is definitely first and foremost built for audio apps, and is missing just about everything to make a 3D game. I think generalizing all the things you listed is far outside the scope of JUCE and falls under “roll your own” territory - where I see JUCE itself being useful for AAA games is quickly building UIs for things like authoring tools. JUCE is definitely no Ogre/Irrlicht in that sense.

1 Like

I think you’re undervaluing anything 3D by spinning that concept as something only AAA games use! Unity games are basically indie hacks (eg: I Am Bread, Surgeon Simulator) - and you’re calling those AAA, the same bucket as Call of Duty, Destiny, Halo? Seriously, anything having to do with just transforms and shaders can add a lot more to the experience/end result, let alone the overall performance.

Even so, in my mind, there’s still plenty missing to do anything useful in terms of 2D games - and the scanline rendering approach is a top deterrent for me personally­, even in the case of 2D game rendering, even on game hacking events.

Not for everything - some of it can be prioritised to build on top, like better shader support and improved rendering capabilities.

But then you have proven the obvious point why indie game developers aren’t adopting JUCE - none of the stuff I’ve mentioned is there and you’re stuck having to roll your own. Why bother with the effort when you can focus on the end result: whipping up anything half-arsed in Unity, or achieving way more cooler stuff using the Unreal Engine (which btw, you should check it out - it’s all written in C++ and is open source - really badass stuff)? IMO, there’s no asking why there are no indie game developers here when the problems speak for themselves.

For the sake of being constructive, if various resources or projects accomplishing any of this with JUCE exist, I’m open to helping assemble it to iterate on.

I have indeed, anything I do when I want to work on game stuff is done in UE4.

What I was talking about are 2D indie games like Hotline Miami, Shovel Knight, Super Meat Boy, Angry Birds (no longer really indie I know). I believe those could be built from the ground up with a lot of heavy lifting done by JUCE. In the case of Hotline Miami 2, Shovel Knight, and (I believe) Angry Birds, they were built on purpose-made engines from scratch. That’s where I believe JUCE would come in handy.

Your points on 2D rendering performance are definitely valid, but I can’t imagine anyone would use JUCE’s software Graphics class for rendering (which is where the scanline rendering happens I believe) - you’d use JUCE to create a GL context and use that directly (but then of course, like you pointed out, we’re back at square zero).

A more accurate statement I could make would be “You can absolutely make games with JUCE, but you need to be advanced to expert level at C++, Linear Algebra, and Graphics, and be prepared to create or bring your own physics, 2D/3D format handling, ECS, and 3D sound bits”. It’s definitely possible for many of the devs who hang around here who have a fairly high skill level, but masochistic and definitely not beginner friendly.

I’ve been wanting to do this for a while - if I do end up making anything, I’ll be sure to post it here.

Also, FWIW, I don’t consider your post to be nonconstructive or JUCE bashing - forums are for discussion, and I enjoy discussing viewpoints with experts from many industries here!

1 Like

Actually, the Graphics class basically wraps a LowLevelGraphicsContext. Furthermore, the main pain point, is that the context for OpenGL uses the EdgeTable stuff internally.

It would be nice to have the ability to override the LowLevelGraphicsContext so as to use (or abuse?) the rendering system any which way you see fit (or is there a way to this already that I skimmed over/forgot?). Graphics and LowLevelGraphicsContext would likely need various extensions, or some API massaging, to allow shaders to come into play too…

Edit: I just realised the LookAndFeel class provides a way to create your own LowLevelGraphicsContext but it appears to rely on drawing to an image (?).

Will keep an eye out. :slight_smile:

Unity is pretty cool to be honest. Plus it has a Native Audio Plugin SDK, so you can use C++ to do your audio processing, as C# is pants for anything fast.


I’ve been reading from this forum since last summer. It’s full of hope and desire that JUCE can become a 2D and 3D graphics GUI powerhouse because of something special that Julian created ( which it is, special ).

I’m researching how to sync a music notation app with DAW software like Logic. I’m still deciding which framework to use for app dev and for the DAW plugin. Doesn’t have to be the same framework.

So, I’m talking from zero experience with JUCE code.

Yes, since JUCE is a good Java-like abstraction layer, I’m wondering why ROLI doesn’t develop a clear graphics extension API: helper classes, wrappers/glue code to support external calls to third party C++ frameworks like game engines, enabling use of their 2D/3D graphics code, and events, etc…

There are commonalities in all frameworks, no? especially in 2D: paths, fills, etc. Developers would write their own external calls. Could ROLI make the code abstract enough? one code base for all possible frameworks? Put the onus on the developer to code and maintain the third party calls ( at first ).

JUCE would probably gain so much interest that an army of developers would join the current 17 contributors to go further, creating and maintaining the third party side of the glue-code for the popular frameworks (which are already cross-platform). Or fork into a separate flexible/extendable front end to JUCE that developers can maintain.

In the Java world, frameworks pretty much all work together. Pick and choose from the best parts of them for one app. Even for GUI development, Eclipse IDE’s WindowBuilder can generate SWT GUI code or Swing GUI code, two ways to accomplish the same thing. ( I miss Java for ease of use.

I think most of my app development work will be the algorithms, and the 2D. I have zero interest in audio effects/processing in general. The DAWs will do that for me.

I would use JUCE’s most basic plugin functionality. Learning JUCE for GUI development seems like a dead-end to me. How many jobs can I get learning the JUCE front-end?

There are many simpler cross-platform DAW plugin frameworks that suit my particular needs.

To me, JUCE’s valuable strengths lie in the unique:

Since these game development frameworks are not competing in JUCE’s space, why not make strategic partnerships to merge current JUCE strengths with more advanced C++ graphics frameworks? This would also expand JUCE to Xbox and Playstation. More developers and more income for ROLI $$

Developing a competitive graphics framework is not ROLI’s priority, why would it be if they purchased JUCE to develop hardware and simple 2D apps? So why continue wasting money to maintain your own graphics API at all? especially when the other offerings are miles ahead? It doesn’t help us or serve us, your clients ( and potential users of JUCE) who don’t use JUCE for the graphics API in the first place.

Just my opinion.

1 Like

Like what? The only other one I know of is iPlug/WDL-OL, and it’s not as nice as JUCE, especially in the GUI department (former user who switched).

What exactly are you looking for here that can’t be achieved with LowLevelGraphicsContext? It’s 100% possible to implement an in-engine texture JUCE can render to in whatever engine you want, then do some simple linear algebra to interact with it via ray intersection on the projected texture.

I’d imagine it’s because because ROLI is a music hardware/software company, not a game studio or video production software company. Performance of the graphics stack is good enough for them for what they need to do. Ever since the acquisition the community/licensees are mostly along for the ride as ROLI pulls resources wherever they need it (see: Blocks).

I’d argue JUCE can’t really compete with modern GUI toolkits as-is since it’s written in C++, not Javascript or Electron or whatever is vogue. It’s a niche product for a niche market that focuses on performance, readability, and a small footprint. The biggest strength of JUCE is that it doesn’t have a bunch of external stuff hanging off it, it’s an extremely self-reliant set of building blocks users can do whatever they want with, GUI included.


C#, according to Unity’s popularity haha

Vogue is Javascript, you know that HTML5 is the answer to all your problems.

But there is a ton of C# flapping in the winds of Unity’s here and gone developers. I remember Unity 2.0 and man was that a different time, now it’s like walking threw an abysmal swamp.

If I had to choose, I would go with Unreal and C++ for anything serious, even if you are an indie. As said above, Unity puts a throttle limit on you if you can’t do shaders and post processing, you will be stuck at “that Unity look”.

Unreal has blueprints and shader node graphs to help intermediates take it to another level.

Yes, WDL-OL was interesting. Not a nice as JUCE, agreed, but simpler for my DAW syncing requirement. I looked at Qt for my standalone app dev.

Eight years ago, I was using pure desktop Java. I wrote a gorgeous responsive score notation prototype app using the Java 2D API, then life got in the way. By the time I resumed, Re-Compose decided to drop Java and rewrite Liquid Notes in C++.

When pros do things or say things, like you guys said in this thread, I listen, evaluate.

Before dropping Java, I briefly looked at jVSTwRapper with libGDX game framework ( Java and some C++), or CodeName One.

For my purposes, I can theoretically use WDL-OL to create a syncing DAW plugin communicating with my standalone Music notation app, written in Qt or any framework I choose. What’s your educated opinion on that?

That sounds more positive than what you were saying earlier:

I’m looking for: I don’t want to waste time being a trailblazer. No matter if I use JUCE alone or in combination with another code/framework, I’m looking for a proven solution, best-practice. If someone has better code than in the JUCE Demo, that inter-works via the LowLevelGraphicsContext ( for example), I want all details and would pay for the working code.

ROLI can also offer us the service of hosting third party documentation of those external solutions for JUCE, making them available to those in the Indie and Pro payment plans and downloadable after a paypal payment for others. Remunerate the developer who provided the solution.

ROLI could find as many ways as possible to incentivize ($), leverage, developer activity similar to the way Apple and everyone else does for their ecosystems but going further, making official scheme(s) to remunerate developers for all accepted contributions bettering JUCE, including direct contributions to the JUCE code base.

Even if it’s a token amount, it’s the principle. No one wants to work for free.

I think ROLI developers know how to create decoupled code with an interface so we can use whichever front end serves our purpose just as easily as in Java and in the Eclipse WindowBuilder example I gave. There are plenty of modern C++ GUI solutions and plenty of possible partners.

Companies like Apple could afford to do everything in-house, yet, where it made sense, Apple stopped wasting development dollars on many proprietary offerings, partnering with others to increase interoperability and value for their customers and shareholders.

They obviously didn’t suffer for it. They didn’t lose control of the core value of their own Intellectual Property adding more value in what they excel at.

I just read how much detailed work Jules put in the OpenGL Renderer, listening, discussing ideas ( ).

So I’ll just shut up now. I’ll try the demo code JUCE provides and assume any slow framerate is my fault until, a year from now, I might be in a position to chime in.