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! 
). 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
Drawableso as to support SVG and/or images
- Maybe something using
- 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.