There absolutely is a need for a robust cross-platform rendering/multimedia solution, more in a similar vein to SDL than Unity or Unreal. The offering of Unity, Unreal, and perhaps Godot is just abysmal when considering that for all of the man hours put into the game development space, that is basically all we got. There should be hundreds of viable cross platform game engines catering to a wide variety niches that continually stretch the bounds of what a game actually is and how it can be represented. Game libraries such as Monogame, Heaps, Raylib, Love2D, etc just wouldn't be that popular if Unity and Unreal are the be all and end all. Adobe Air was once a popular choice (a very large number of top 50 app store games were built with Adobe Air) and I'd wager still would be if it didn't collapse under its technical weight.
Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable. If it wasn't so insanely complex, and the technical barrier towards making your own engine is reduced, the tired cliche of "don't build an engine" wouldn't hold as much weight, and it opens the doors to building a bespoke, fit for purpose engine for every game you create. Don't underestimate what an individual or small teams can produce if they are operating on a solid platform that facilitates a rich ecosystem of tools.
> Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable
I couldn't agree more. My goal is not to simply build "a better game engine", but to make this kind of low-level tech accessible at a higher level and with much better dev tools to a broader class of developers and applications
> Don't underestimate what an individual or small teams can produce if they are operating on a solid platform
This gets into my motivations for building a company - larger companies have the resources to build moats, but often can't quickly realign themselves to go after novel technical opportunities. It's not either / or - both models exist for very valid reasons.
Have you seen Kha by any chance? It has similar goals. I find it quite awesome, but it won't gain mass adoption for a bunch of reasons. https://github.com/Kode/Kha
I find this tech and tooling really quite amazing (just look at how little source code Zui has) given just how small the ecosystem around it is. I think Kha really illustrates what can be achievable if the lower levels have robust but simple APIs, just exposing the bare minimum as a standard for others to build upon. It really suggest taking a look at the graphics2 (2d canvas like) api.
For the kind of project I work on (mostly 2d games), I think it would really awesome if your framework also supported low level audio, and a variety of inputs such as keyboard, mice, and gamepads. If it also had decent text rendering support it would basically be my dream library/framework.
Interesting! Had never heard of it before, will check it out. The point of Haxe seems to be as a meta-compiler to generate code for a bunch of different languages/compilers? The same spirit of the Wasm dev experience but without the runtime.
Text / fonts is very much on the roadmap! For input and audio I would have to think through the scope.
> Game libraries such as Monogame, Heaps, Raylib, Love2D, etc just wouldn't be that popular if Unity and Unreal are the be all and end all.
Just because it happens, doesn't mean it makes sense.
Anyway, people write their own game engines, and programming languages for game engines, because it is intellectually stimulating to do so, and something you spend 100h/wk to yield 1h of gameplay is still giving you more gameplay than something boring you spend 0h/wk on.
Then, the people who use those engines you are naming, they end up porting to Unity anyway. If you want to deploy on iOS and Switch with one codebase, it is the only game in town. And that's sometimes 60% of revenue.
> Don't underestimate what an individual or small teams can produce if they are operating on a solid platform that facilitates a rich ecosystem of tools.
Unity fits this bill exactly. I too want more competition. But in the real world I live in, if someone were to ask me, "what solid platform should I choose to make my multimedia application, as a small team, that also has a rich ecosystem of tools, and will enable me to make pretty much anything I can think of?" I would say, use Unity. Because I want them to succeed.
Two high profile examples, Celeste and Deadcells use Monogame and Heaps (Haxe). They weren’t ported to Unity. Celeste and Towerfall Ascension are two examples of very high quality games that bucked the trend and just used a low level renderer (Monogame). IMO they are better because of that.
But besides that point, the very reason why many games are ported from their niche library to Unity or Unreal is mostly just for cross platform support. Not because the game creator has a preference for Unity or Unreal. They are forced into it through lack of choice if they want cross platform. If Love2D, Phaser, Flixel, and any other niche 2D game library had an easy way to target consoles they would get a whole lot more use, but they don’t because the lower levels are extremely complex and engine/framework/library developers can’t support it. WebGPU appears to offer a path forward in that regard.
> the very reason why many games are ported from their niche library to Unity or Unreal is mostly just for cross platform support.
Indeed.
> They are forced into it through lack of choice if they want cross platform... because the lower levels are extremely complex
That is what I am saying. There are countless indie game engines of great repute, but because they are "1 guy," they cannot reach feature parity with Unity. They never will.
The Blizzard that developed the Overwatch engine had immense experience and a notoriously frugal (in terms of employee pay) culture. It still cost them about $100m and many years to develop a great engine for 3 platforms (Windows/Xbox, Switch, PS5). What hope does Godot have with $8m, or MonoGame with kopeks?
Nobody can vibes their way past the math problem of multi-platform game engines.
This is only controversial because Unity received so much ill will; and, that the indie games business and social media are very sensitive to vibes.
> WebGPU appears to offer a path forward in that regard [like supporting the Nintendo Switch].
While I would love for this to be true, it is significantly more aspirational than saying that because of Game Porting Toolkit, DirectX offers "a path forward" on macOS.
I suppose it should be considered where the abstraction actually exists. If the abstraction exists in logic or mathematics (ie. a triangle is a 3 sided polygon) it probably doesn't make much sense to consider the ramifications that thought occurs in a physical brain that can fail. On the other hand if the abstraction is physical (ie, hardware), then the fact that it is bound by physical law is obviously implicit. Software encompasses both physical and logical abstractions, so you need to pick a lens or perspective in order to actually view its abstractions.
Also, for even things like physics there are many simple ways to do things. Take Towerfall's arcade physics for example[1]. In under 100 lines you can create the basis for your platformer game. Sure, it's not just pluggable into other pre-existing solutions, ie tile maps, but at least you aren't endlessly hacking all over the place to tweak Unity's physics into submission to get the controls feeling right for your simple 2d game. There is a massive wealth of gamedev knowledge that doesn't seem utilised to its potential because existing engines want sell their pre-canned solutions. I think what the gamedev scene needs are more tools like LDTK[2], with more thought given to how such tools could interop, and a better selection of low level rendering libraries (like Monogame and Raylib) with very robust cross platform support and dead simple build systems (or none at all).
I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.
When people say to build a game not an engine they mean “don’t copy the patterns of general-purpose game engines and build something specific to your needs”. There’s not game that doesn’t have bits you can point at as “the engine”. Lots of people get stuck “making the engine” to make their game rather than making the specific engine bits they need as they go.
That said this was the status quo before Unity and whilst it shipped games the asset pipelines and editors in engines like Unity and Unreal are much more productive for the non-programming portion of the team. As well as providing a shared framework that makes it easier to hire and train developers. Not to mention easier porting and so on.
I do think the solution to part of this is an open-source scene editor/flexible tool that has some defined interface that any engine can implement like a language server or similar.
I have wondered if the UFOs specifically exist in a plane that will always be at the edge of our awareness. They aren't so much moving through physical space, but though our collective consciousness. Similar to how a physical person may temporarily exist in your mind, a UFO may temporarily exist in the physical space, and attempting to "capture" them is like trying to control a dream.
It just seems to be the same guy going on the podcast circuit talking about the Tic Tacs, and all I see is a video with a black blob in the centre. Have you got any links to back up your claims about all these people telling their stories?
I don't see anyone mention affiliate links when talking about the indie/old web. Affiliate links were such a crucial element to the early web 'surfing' experience. It's a pretty shitty web without those affiliate links, IMO, and the only means of discovery is generally through some giant platform.
Yep, when talking about affiliate links I always think about commercial stuff: links with a referral that will give the site owner some commission if you buy something.
It's either webrings or those widgets that people used to have in their blogs that were called things like "friends sites", "interesting sites" or things like that. (I used to have one but can't remember the name I gave it)
Ah in the olden days, quite a few hobbyist sites used to maintain a link of other recommended sites in the same niche in the sidebar, with the idea being that if you like the site you're reading, you'll probably enjoy these other sites too.
This made them a very easy way to find new sites and communities, especially in fandoms like the ones for the Legend of Zelda, Pokemon, etc.
You can see a working example in the right column of this longtime Pokemon site:
Outside of Vue, and maybe Angular, are there any other stable alternatives with a decent ecosystem? I'd love to hop off the React train, but I haven't found anything that compares to the experience of just using create-react-app with Typescript support.
I have been using it for a month now and love it. If you are coming from react the API is familiar enough that you can get productive in a day or two. Reliance on observables is a big plus for me (no virtual dom diffing) and the dom reconciliation is very similar to lit. Check out the author's blog posts [2] for more details.
If are into jamstack, Astro [3] has good support for solidjs already and offers an easy way for selective hydration of dynamic parts of the UI.
The component ecosystem is a bit lacking compared to react/vue, but it pairs well with pure css libraries like bulma/daisyui or webcomponent libraries like ionic/shoelace.
And you can also wrap your solid components as web components and use them in a larger app without converting it all to use solidjs.
If you haven't check out ember-cli + ember.js latest Octane release. Full typescript support, thriving community, lots of companies using it, lots of active development.
Aside from the bustling ecosystem, Surplus has been around for a long time, consistently beats benchmarks, and is quite lightweight and unopinionated. I've used it for a lot of projects, small and large, quite successfully.
How do you manage the lifecycle of objects with the observer pattern? I saw an example of the pattern below that is crucially missing a 'remove' function to unsubscribe from the subject. Like when using events at the app/controller level, I have found a layer/glue starts to form associated with the adding and removing of subscription handlers, and it is this subscription management layer where the majority of complexity and bugs lie. Being inspired by immediate mode renderers, this is what makes React so great - it basically eliminates this entire layer. I might have PTSD working with observers and events from my AS3 days, but if I were building a single page app I wouldn't use the observer pattern over React unless there was a robust way to manage the subscriptions. Perhaps I am overcomplicating something that is actually pretty simple, but I imagine using the observer pattern by itself doesn't really scale beyond the component level?
Yeah that's an interesting problem. I mean the simple answer is you just make an unsubscribe method. But that doesn't solve the layer of adding and removing subscription handlers.
Using a subtree, childlist MutationObserver, you can implement a disconnectedCallback for non-custom elements. In the callback, you can clean-up any event handlers that you have added to the element yourself.
Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable. If it wasn't so insanely complex, and the technical barrier towards making your own engine is reduced, the tired cliche of "don't build an engine" wouldn't hold as much weight, and it opens the doors to building a bespoke, fit for purpose engine for every game you create. Don't underestimate what an individual or small teams can produce if they are operating on a solid platform that facilitates a rich ecosystem of tools.