Future direction of Indigo - where to next?

[davesmith00000]

Development work on Indigo appears to have slowed down. That change of pace could be attributed to the fact that I've also been working on Tyrian, or that I'm building a new demo/game, but mostly it's because Indigo now does far more than I ever planned for it to be able to do.

The initial goals have been met. Where should Indigo go next?

Restating the mission

There are a number of possibilities, but before I list them I think it's worth restating the purpose of Indigo:

1. I wanted to build games / mess around with game dev in Scala using FP.
2. I wanted to try and show that Scala wasn't all microservices and big data, that creative projects were just as possible.
3. I hoped to inspire some people to have a go.
4. I hoped to inspire more (and better!) Scala game engines to pop-up into existence.

Possible next directions

Options I've been thinking about (more information below):

1. Modernise and Expand
2. Expand to new platforms
3. Build a game
4. Build an editor

Modernise and Expand

WebGPU

Within it's current constraints, Indigo latest the latest and greatest of the available technologies, save one: WebGPU.

Adding WebGPU support is simultaneously something I'm quite interested in, but that also has really dubious value, and that is off-putting.

WebGL adoption rates are slow. WebGL 1.0 is everywhere, WebGL 2.0 has just finally been added to Safari years after other browsers implemented it (and it has issues). How fast will the world (devices/browsers) move onto WebGPU? Who knows.

But more importantly, what benefit does WebGPU bring to a 2D pixel art game engine? No one that I'm aware of is using the current WebGL 2.0 stack to it's full potential. Moving to WebGPU feels like a long term inevitable move, and it might sound exciting on an announcement post, but I'm fairly sure that it wouldn't encourage many/any new users or produce new or better games by itself.

More than Pixel Art

The choice to focus on pixel art, like the choice to focus on Scala.js, was a way of constraining the scope of the project to something manageable that I was personally still find exciting.

I accept though that Pixel art is a bit of a marmite subject: Would more people start using Indigo if it supported super smooth 2D graphics too? It's a lot of work, how would we find out?

Expand to new platforms

Before I get into the nitty-gritty: The big problem with adding new platforms is the maintenance cost.

The JVM runs on anything, there is no maintenance cost!

I get that a lot, it is not really true. Lets pretend for a moment that the JVM bit itself does indeed work identically everywhere, or rather that through the magic of Scala compilers I can just target different platforms and OS's, you are still left with the problem of supporting all the GPUs and shader languages (not to mention audio, IO, networking, storage, etc).

Yes, you can look at abstraction layers for some of that, but there are complicated trade-offs to consider. It is already a lot of work testing for Electron + a good range of browsers on Windows / Linux / Mac where I only use Web-tech + WebGL 2.0.

Having said that, adding to the maintenance burden is genuinely acceptable, but the value of doing so requires some articulation.

The JVM

"Does it work on the JVM?"

This comes up a lot. If you're doing Scala there's a sort of expectation that it should a) work on the JVM and b) that there is value there. In this day and age neither is true in my opinion.

Scala.js and Scala Native are amazing things. The JVM is well suited for long running processes of the kind found in server-side platform building, but is it really a good choice for everything else? Maybe not.

Yes, there are Java/JVM game engines out there, and if you focus exclusively on Desktop gaming then the JVM is a totally viable option, but you cannot port it to console, and it does not run on the web. (Scala.js on the other hand works on Desktop, Web, and Mobile for not much more effort!)

JVM support feels like a hygiene factor, it's expected and people are disappointed when it isn't there, but I'm not convinced it adds any actual value unless your plan is to target Desktop exclusively.

Scala Native

Scala Native is an interesting option, either adding support for Scala Native or even perhaps abandoning Scala.js in favour of WebAssembly. The promise here is that with a lot of effort, we'd gain the ability to target any platform i.e. Browser, Desktop, Mobile, and Console.

But would that actually increase adoption? Would it encourage anyone to use the engine? I'm skeptical.

Sticking with Scala.js?

The beauty of Scala.js is that it provides a good abstraction away from the graphics hardware, and runs well on both Browser and Desktop (and even Mobile!), at a the cost of a performance penalty (that most people won't be seriously affected by for 2D pixel art games). If there were thousands of people making games and all of them were clamouring for better performance than the choice to move away from Scala.js would be compelling ...but we don't seem to be there yet.

Build a game

If you've been following the recently news about Unity, you can't have missed that the world's Unity devs are unhappy. Unity has shutdown the division that it finally set up to make games internally - i.e. to eat it's own dog food and improve the engine based on real usage and experience.

Many of the recent Indigo improvements have been based on the same idea. I (and others) have been trying to use Indigo to build games and demos and this has led to the discovery of many missing features and improvements that could be made.

One tactic is to make further development entirely use-case driven. Either myself or someone else builds a substantial game and we improve Indigo to meet their needs. For example: No one has ever published a desktop game using Indigo, and what that means is that although we have basic support for desktop apps built in to aid development, there is just a huge pile of things we don't even know we're missing that would help people package and distribute their games!

Call it a period of consolidation if you like. The appearance is that Indigo development has slowed down, but what is actually happening is that it's being hardened up through real world battle testing.

Build an editor

Indigo was originally designed to be a code-only engine, however, as time has gone on I've begun to suspect that there are only so many game builders out there who are prepared to put up with an entirely text-editor based game building experience.

I have ideas about how to build an editor (FP doesn't map to a GUI editor experience in quite the same way the OO does) but it's a massive undertaking, and again the question is: Is it worth it? Will it aid adoption?

An interesting side note here is that building an editor is related to the previous point "Build a game". In the act of building a game, I've realised that I do also need more tooling, and so building an editor to meet my needs - even if no-one else cares - has value.

So... where to next?

If you have an opinion on any of this, please feel free to share it. I'm well aware that most of the above is me speaking from inside my own little bubble. Maybe I'm dead wrong and adding JVM support really is the answer!!

If you aren't comfortable leaving a message here, do come and find us on Discord.

Let me know!

[Daenyth]

I skimmed the post above because it's a lot, but here's some of my lukewarm takes:

• I like that it's just pixel art, that's a great creative restriction that I don't think needs to be shifted right now
• I'd really like to see more of a toolkit of useful premade building blocks. For example, ways to do collision detection - that's a lot of stuff to write from scratch. Just having a library of "here's an example of how to solve X" would be great, regardless of if it was easy to import. It doesn't have to be generic or solve every problem, just solve a specific problem really well. And then people can reuse it or fork and tweak to meet their needs

[davesmith00000]

Lukewarm takes are very welcome! Thank you. 😄

The collision detection example is interesting. I think that's the kind of stuff that would come out of game building. For example, because I was finding my game hard to scale (in terms of the mental gymnastics of working out what was going on where) I devised a sort of component pattern to help keep related functionality together without breaking the idea that you're building in pure functions. I haven't advertised that anywhere because I consider it a work in progress, but maybe that sort of thing (or path finding, or collision detection, or raycasting, or...) would be good to have examples of and small supporting implementations for - even if they are a bit 'use case specific' or kinda rough n' ready. 🤔

[Daenyth]

Perhaps the solution to having more off-the-shelf tools is just "write more games", and then as a part of writing the games, different problems will need to be solved.

[JD557]

Here are my thoughts on it (I already shared some feedback on Discord, but would rather share some more detail here).

First of all, my general thoughts on Indigo:

• I think Indigo should focus on indie games/game jam entries for now. AA/AAA games should be out of scope until the engine is a bit more "battle tested".
• I expect Indigo to be "performant enough" for the use cases it targets.
• It should be clear how to start creating a game on Indigo.

Modernise and Expand

WebGL adoption rates are slow. WebGL 1.0 is everywhere, WebGL 2.0 has just finally been added to Safari years after other browsers implemented it (and it has issues). How fast will the world (devices/browsers) move onto WebGPU? Who knows.

For me, this is a very strong reason to not support WebGPU. Small games really benefit from being playable in the browser (or at least having a demo on the browser).
This is especially true now with the amount of gamedev scams going on Discord ("Try my game" links that point to executables stealing Discord credentials). It's really hard to promote an indie game without either having a JS demo or being able to publish on a reputable store like Steam.

More than Pixel Art[...] Would more people start using Indigo if it supported super smooth 2D graphics too?

Is Indigo able to render a "pixel art game" with a 1080p internal resolution? I understand that there are differences between a pixel perfect and a smooth 2D renderer, but if the engine supports a high enough internal resolution and some scaling capabilities, this seems like a minor problem.
OTOH, if the engine does not support this due to performance limitations, maybe it would make sense to look into improving the performance first.

Expand to new platforms

Overall, I think it's "impossible" (or at least very hard) to have an engine like Indigo keeping an high performance while targeting multiple platforms. I've written some simple cross-compiled games in the past and just accepted that they would have crap performance.
Small things like "load an image into VRAM" can have quite different interfaces in JVM, JS, and Native (Maybe this example is not a problem if Indigo uses WebGL/OpenGL wrappers, but there are multiple other problems like this).

This is also particularly annoying when dealing with file formats. For example: what kind of images formats will you support? Are you going to write your own image decoders or use platform specific ones? If you use platform specific ones, what happens when one platform supports one feature that another platform doesn't (e.g. The BMP spec has some weird features like JPEG compression)?

As such, I think the only way for Indigo to be performant is to pick a single target, and JS seems the safest bet (as it can target both browser and desktop). That means that we probably won't see any AAA game released on Indigo, but in my view that's OK.

Build a game

For me, this is the most important point. I'm sure that most people picking an engine will first search for "what games use X".
Right now, this is a major flaw for Indigo. There are some tech demos in the site and that's it... the only actual "game" is a 1-bit snake game. If that's the Indigo killer app, I might as well just write my own engine. (I know this sounds a bit harsh. Just to be clear, I'm not criticizing Indigo, just trying to point out that the showcase is quite underwhelming considering what the engine can do)

Also, having an open source game would also work as an example of how a game is structured in Indigo (it would be nice to also have some more entries in the "Guides" section).
On that note, it would also be nice to have an "expanded pirate demo" written as a tutorial: just a single level with a goal and maybe some coins to collect that increase a score. This might work better as an introductory project than a full game.

Build an editor

[...] as time has gone on I've begun to suspect that there are only so many game builders out there who are prepared to put up with an entirely text-editor based game building experience.

Yeah... unfortunately, I have the same feeling. Which is a shame, because I think it's going to take quite some effort to create an editor 😞

An interesting side note here is that building an editor is related to the previous point "Build a game". In the act of building a game, I've realised that I do also need more tooling, and so building an editor to meet my needs - even if no-one else cares - has value.

Maybe this is the safest approach? Build some tools (or at least integrate with other tools) that you need for the game and see if they are useful to others?

[bilki]

For me, this is the most important point. I'm sure that most people picking an engine will first search for "what games use X".

Well, I think we may solve that by adding a new page to the docs containing the indigo-awesome list of games (simple or more sophisticated in some cases) that already use Indigo. I think we may ask on Discord about then, and probably would have a decent number of them.

For the rest of your comment, I agree with most of the points made.

[aronfiechter]

For me, this is a very strong reason to not support WebGPU.

I think I've read somewhere that WebGL 2.0 adoption is kinda slow also because WebGPU is supposed to be much better, more universal, more supported. It will still take a lot of time though, I guess.

[davesmith00000]

This is great feedback, thank you for taking the time to write it. All makes sense.

Is Indigo able to render a "pixel art game" with a 1080p internal resolution?

With regard to this question and that topic in general. You can certainly set Indigo to be magnification 1:1 and render all the pixels. You can even tell specific layers to do this, I was playing some games at the time that were pixel art but had these gorgeous HD UI's and character graphics and I wanted to be able to do that.

What you cannot to, is anything other than pixel art. You can't move by a sub-pixel or sensibly use anti-aliasing or anything like that. The Shapes will always have jagged edged curves at the moment. This can be considered a creative constraint at the moment, but it does rule out certain 2D game styles.

[aronfiechter]

Modernise and Expand

I agree that WebGPU will need to happen at some point, but it's still too early and definitely not essential for now.

Expand to new platforms

This could potentially "ruin" indigo because of performance problems and so on. I also think that the web is already universal enough. There might be an argument for a more streamlined packaging of games as executables, likely through electron, but I don't know if this is something that is supposed to be done externally using other tools.

Build a game

Yes, absolutely. This 100%. Guide development through what the community needs. I also like the idea of collision detection. Maybe similar features could be all part of a plugins project?

Build an editor

This one sounds cool, but also high investment and potentially low reward.

[davesmith00000]

The editor one is interesting. My early thoughts on the editor experience is that it's more like an game preparation pipeline. The engine itself is code only, and you will always have to write code but that's the fun bit! ..but what about the laborious stuff?

I think what the editor would do is take some of the pain out of things like coordinating assets, designing/generating shaders, configuring your game, generating game data, preparing and hooking up fonts - that sort of thing - so that you the programmer are more focused than ever on writing your game play logic. I think there's value to be had there because it would hopefully be a productivity gain.

For example: You put together that awesome black hole shader. What was your workflow like? Would it have been helpful to get faster feedback?

[aronfiechter]

For the black hole, I started from this shadertoy (https://www.shadertoy.com/view/ftKSDm), tried to understand it by playing with it, then slowly converted it to the format used by Indigo. I kept running runGame and fixing errors until it finally worked.

I guess a mode streamlined shader editor similar to shadertoy, to create custom entities, would definitely help with this.

As for other things, like you said coordinating assets, what would an editor for that look like? What would the advantages be over a plugin with a simpler API?

[davesmith00000]

As for other things, like you said coordinating assets, what would an editor for that look like?

I think we need a prototype to find out. 😉

[Iltotore]

About the current implementation

I think Electron is a huge drawback of Indigo:

• The disk space and the RAM consumed for potentially small apps (using Tyrian)/games is awful to me and a big blocker.
• Packaging is also a nightmare with Electron

Asking other communities, it seems that this thought about Electron is shared.

JVM

The JVM is a really good piece of technology with great performances and the ability to run on Linux, Mac OS, Windows and Android. However, the JS support is almost inexistent except TeaVM which.. behaves like Scala.js. I also understand that the cost of maintaining both several Indigo/Tyrian implementations would be hard to handle.

ScalaNative

I find ScalaNative very easy to use and it allows console support but here comes two concerns:

• Will the code (especially graphical components) be easily portable across platforms without subtleties?
• The compilation to native code is a bit slow making app debugging/multiple recompilation painful

Sticking with Scala.js ?

So with ScalaJS, we can target the browser, mobile, but the desktop implementation uses Electron. What if we switch from Electron to Tauri or Neutrino.js?

Tauri is in my opinion a pretty good compromise between portability, maintenance cost and lightness. Tauri uses the OS's web renderer, featuring way lighter binaries at the cost of (maybe) small platform-dependent changes but not as significant as ScalaNative or maintaining JVM+ScalaJS implementation.

[davesmith00000]

Thank you for taking the time to add to the discussion, some good points there, I'll try and tackle the two big ones that I think others might find interesting.

ScalaNative

Will the code (especially graphical components) be easily portable across platforms without subtleties?

Short answer is no. At the moment this isn't much of a problem because we only have to worry about GLSL 300 and a fairly consistent (but certainly not perfect... mostly lookin' at you Safari...) abstraction layer which is WebGL 2.0. Other engines have tooling to go from (it seems to me) HLSL to a multitude of other shader dialects, and no doubt have a lot of code, and probably teams of people, finding ways to smooth other the hardware / platform differences to get a reasonably consistent experience. Not having to do all that is a massive saving of effort.

Electron

First, let's bust a myth! 😄

Indigo games are in no way constrained to Electron.

What Indigo games are, are tiny, simple, static websites that just serve your game on one page. What Electron is (waves hands), is a Node.js webserver serving up that website into a baked-in version of Chrome, where the whole thing is wrapped up in an executable. Knowing that, it should be apparent that actually you can already run Indigo games via a Browser, Electron, Cordova, Tauri, ScalaNative + WebView... and anything else of that sort.

So no real constraints, just needs a little effort put in to set it up.

Why then do we appear to be bound to Electron? I suspect it is because that is the reference implementation provided by the plugin. It sort of looks like Electron is the only platform supported out of the box, doesn't it? In fact, the plugin also gives you a little-known reference implementation for Cordova too!

Moreover, in practice, if you wanted to bundle up an Indigo game with Electron or Cordova in order to distribute it, the reference implementations produced by the plugins would be woefully insufficient (I imagine - I mean I really didn't spend long on them...), and you'd want to look at properly setting all that stuff up yourself.

Why are they there at all then? ...it just makes the development and testing cycle faster and more fun!

Electron and Cordova are notoriously difficult to package up, this wildly circulated knowledge. I haven't tried it myself yet sadly. But a WebView based solution (like Tauri) is not a silver bullet. WebView uses your platform's native browser, so rather than having a consistent version of Chrome to build against on all platforms (which is not perfect either btw...), you now have all the usual browser compatibility problems you expect with web dev. Except it's worse than that, because you also need to know about the WebGL 2.0 implementation differences on the platforms / browsers. Compared to just developing against Chrome, your game will now also need to be able to cope with the possibility of running in Firefox with its noticeably slower JS engine, and Safari which can only accept 1/4 of certain kinds of shader data.

I really think that either option/approach is totally valid in truth, but the important thing to note is that this isn't a choice between a demonstrably bad option and a clearly good option, this is more like "choose your poison". 😬

(If anyone thinks I'm wrong about any of that, please do let me know. I frequently am mistaken, this is all just stuff I've learned along the way, and I value further correction. 😃)

[spamegg1]

Scala Native support would be great!

It's improved a lot since; it's got multi-threading support now, and someone was even able to get it working on a PlayDate game console.

There is source-level debugging support added recently too.

I think porting across platforms will be probably tricky. But I don't know too much, it's best to drop by the Native channel in Scala Discord, the main contributors are often there.