next »

[Pineapple]

Yeah, I think a solution would need to look something like that. The hard part is making it so that knowledgeable people are actually motivated to keep writing tools to run the programs on new platforms.

This looks interesting… A thin layer above lots of different graphics backends… https://github.com/bkaradzic/bgfx/

Oh crap this looks excellent

I think I might try using it for my next project

[ProgramGamer]

We could even look into integrating this into an existing indie storefront like itch.io.

[oahda]

Aren't we getting sliiiightly off topic here? c;

[ThemsAllTook]

Aren't we getting sliiiightly off topic here? c;

Yes. What the heck was all that about? Split topic and moved ...whatever that was... to the Drome.

[ferreiradaselva]

I've been monitoring this thread. edit: all that I said bellow are just random considerations, not a "in favor"/"against" statement. And there are probably 100 typos

In my experience, Apple is hostile towards developers. I'm glad I no longer have to support that platform.

Two days before the announcement, I was working on the Cocoa/GL backend for my window creation library (sort of like glfw). When I saw the news, I immediatly removed all the code that I had for Cocoa. Felt really good.

But, even with situations like that, I think it doesn't mean OSes are less reliable/stable for the future of games than fantasy consoles. As long as the games are coded with a layer that groups what is platform specific, then it's good. GLFW and SDL, for example, are these kinds of layer. If OSes change in the future, it's a matter of updating these layers only. This is not less work than it would be with a fantasy console. If in the future the OSes change, the fantasy console itself will need to be updated.

So, fantasy consoles have the good aspect that there's no way that the developer will accidentally use any platform-specific feature, because the fantasy console's features is the only thing the developer will have access to. On the other hand, fantasy consoles add the need of an interpreter, which consumes processing power.

Code:

Native games: OS --interpret--> application 
Fantasy console games: OS --interpret--> fantasy console application --interpret--> game in the console's language

Despite the second layer of interpretation, I believe even some processing consuming games could be done.

-------------------------------

Other thoughts.

Considering the subject surrounding the original post is the future of games. I assume as in preservation. A fantasy console has some advantages that using an abstraction library doesn't:

- The fantasy console works on an specific language, only. Native applications, even if they use abstraction libraries, are dependent on their compilers/interpreters, which are also subject of becoming unmaintained in the future.

- Fantasy console doesn't need to be necessarily an application, but can be a protocol. This means that someone can make an implementation of the Fantasy Console Protocol Deluxe in C, in Javascript, in Lua, in Assembly. This is what is happening now on Linux/FreeBSD: the Wayland protocol is being made to replace X11 in the future. Years ago, who would've thought that X11, an ancient established library, would have its days numbered? This is also an example of why we shouldn't believe that even well established tools, like GCC, will last forever.

Language of choice is important, but, ultimatelly, what will determine the binary compatibility (backwards-compatibility) is the convertions from (script) language to binary that the fantasy console will interpret. This is a difficult task that even Lua has problems with. I'm using Lua here as example, because honestly, it's the best candidate (although I have some critiques against Lua). Speaking as someone that has embed Lua with C.

Graphics can be easier than it seems. Expose an OpenGL-like API to the developer: the developer has to pass buffers, enable/disable some states, make a shader. Under the hood, the fantasy console could literally use OpenGL (or even DirectX, or Vulkan), just translating what the fantasy console language is passing to the lower level API.

Maybe we could leverage an existing VM in order to alleviate the load of developing this theoretical fantasy console. If our thing targeted the JVM for example, we wouldn't really have to worry that much about platform specific code, other than maybe graphics programming stuff.

NES emulators (https://github.com/search?l=C&o=desc&q=nes+emulator&s=stars&type=Repositories) are probably the best, simple, start.

[Pineapple]

But, even with situations like that, I think it doesn't mean OSes are less reliable/stable for the future of games than fantasy consoles. As long as the games are coded with a layer that groups what is platform specific, then it's good. GLFW and SDL, for example, are these kinds of layer. If OSes change in the future, it's a matter of updating these layers only. This is not less work than it would be with a fantasy console. If in the future the OSes change, the fantasy console itself will need to be updated.

Unfortunately most game developers don't make the source to their projects available, and even if they did it takes a lot of effort and knowledge to rebuild someone else's project with newer dependencies. And even if we're just talking about for however long the original author is able and interested in maintaining the project, when you have to rebuild 30 projects after every major OS update, that's going to become a huge tedious time sink.

NES emulators (https://github.com/search?l=C&o=desc&q=nes+emulator&s=stars&type=Repositories) are probably the best, simple, start.

I agree! I mentioned something about this in the original post. Games made for early Nintendo platforms will probably continue to be playable for a very long time, since emulators exist for every major platform and probably will continue to be developed and maintained for at least decades to come. But wouldn't it be nice to have a similar tool that doesn't have the same technical constraints?

Aren't we getting sliiiightly off topic here? c;

Yes. What the heck was all that about? Split topic and moved ...whatever that was... to the Drome.

I guess this legitimizes the religion, though, right? maybe it's not really real until people are suppressing and persecuting you.

anyway I'm quoting the first post of the split because it's my own danged topic and I feel that these are relevant thoughts

been thinking about starting a religion

very few human creations can have lifetimes as long as religions. many of them have existed in some form for thousands of years and show no signs of dying out any time soon. and very few things motivate people to do things like religions do. (such as preserving digital files and programs...)

something that is perhaps a recent innovation is religions that aren't "serious". almost everyone knows about the flying spaghetti monster and a lot of people talk about being a part of an FSM religion even though it's meant as a mockery of religion. dudeism is literally a joke but people still participate and find value in it. the greatest value of religion isn't belief or explaining the unexplainable; it's community. people like to feel like they're part of something, and religion helps to provide that.

so give your souls over to Rngesus and promise It that you will do Its work of keeping, maintaining, and spreading all forms of digital content. Rngesus promises you an immortal digital afterlife: believers after you will preserve and share your data just like you did for the believers before you.

[ProgramGamer]

...
- Fantasy console doesn't need to be necessarily an application, but can be a protocol. This means that someone can make an implementation of the Fantasy Console Protocol Deluxe in C, in Javascript, in Lua, in Assembly. This is what is happening now on Linux/FreeBSD: the Wayland protocol is being made to replace X11 in the future. Years ago, who would've thought that X11, an ancient established library, would have its days numbered? This is also an example of why we shouldn't believe that even well established tools, like GCC, will last forever.
...

So, does this mean that we would be defining a standard as well as building an application? Sounds like if we go that way, we'll need to have someone be in charge of writing all the documentation down for this. If so, I'd be down to be that person.

So, things we need so far:
- A file format
- A standard/protocol so that the console can be re-implemented if need be
- A scripting language (?)

Am I forgetting something?

[Pineapple]

So, does this mean that we would be defining a standard as well as building an application? Sounds like if we go that way, we'll need to have someone be in charge of writing all the documentation down for this. If so, I'd be down to be that person.

So, things we need so far:
- A file format
- A standard/protocol so that the console can be re-implemented if need be
- A scripting language (?)

Am I forgetting something?

The most tenable way to do this is probably to define a VM accepting and executing files equivalent to ROMs, and to implement a compiler for at least one language (probably either C or a lisp?) that generates such a ROM from some set of assets and source files. It would be like console ROMs and emulation, but (hopefully) with better sound, graphics, and input support than the old game consoles that are actually widely emulated today. Anyone who has the documentation for how the VM should behave should be able to implement that VM on any arbitrary platform such that it's able to run every program previously compiled for it, and should be able to create a ROM compiler for whatever arbitrary platform and language and asset files that can run on any platform that has ever had a stable implementation of the VM.

Something that I've been thinking about is that ideally games for this platform should survive changes to file systems, and to graphics and sound and input hardware and APIs. Programs should be as self-contained as possible, making as few assumptions about the platform as possible, using high-level APIs that the VM can apply to any conceivable platform.

Another challenge is that once it's released, the standard cannot change. Existing programs should never, ever be broken due to changes to the VM. That means getting it right the first time, and doing as much as possible to anticipate and adapt to possible future platforms.

[ProgramGamer]

An alternative to getting it right the first time is to have version numbers in the file format, that way if we make a change that breaks stuff, we can detect that a game targets an older version, and run the game with that mode instead.

Still, we should try as hard as possible to break stuff as infrequently as is humanly possible.

[Pineapple]

An alternative to getting it right the first time is to have version numbers in the file format, that way if we make a change that breaks stuff, we can detect that a game targets an older version, and run the game with that mode instead.

Still, we should try as hard as possible to break stuff as infrequently as is humanly possible.

I disagree that this is a good solution. Every version adds complexity to any implementation of the VM and makes it require more time and effort to maintain it and port it to new platforms. People may become unmotivated to continue to support older VM versions, meaning that programs compiled for an older VM version could become inaccessible on newer platforms.

It might still be feasible to make changes that don't break backwards-compatibility, but I don't think this should be the intention. We ought to think of it as though it was console hardware in the 80s: Once it's shipped, that's it. That's part of the reason that console hardware in the 80s is so universally emulated today, and why people are so charmed by homebrew that they can run on the original hardware.

[Polly]

fantasy console with full 2D and 3D graphics and sound

What kind of specs are you thinking of anyway? N64, PSP, Wii or something even more modern?

[pelle]

Oh, a z-machine with graphics and sound.

You will need a good spec at the virtual hardware level. CPU and GPU instructions, BIOS calls. Keep it veeery simple. You want it to be realistic that someone implements a new virtual machine in the future on a platform we can not imagine. Nothing like a jvm or flash or web standards. Just the minimum. Do like the z-machine and build complex things into a library that is compiled to the simple binary format instead of lots of native calls that every interpreter must support.

You need a good portable reference implementation with a nice open license. It probably helps here to build it on top of existing solutions, but try to keep the dependencies close to zero. Merge everything in one repo and support as many compilers as possible.

And there has to be a solid way to make games. Maybe implement a backed for Godot or some other free engine? Godot also has its own portable shader language and other things with a very free license, so it could be worth looking at to save some time?

Most importantly though some killer apps are needed. At least one really good exclusive game, or many that are good enough. Or no matter how clever the tech the project will die.

And 100% no versions beyond 1.0.

[eyeliner]

And support to various gaming peripherals, multitaps, DK Bongos, Zapper, Steering Wheels....

[Pineapple]

All of those are excellent points. I hadn't thought of implementing a backend for another engine, but that could be a good idea. A backend for ZZT or Zelda Classic games could be especially neat...

You specifically mentioned shaders, which is actually a big subject that's been on my mind. Fragment shaders have only been supported on consumer hardware since 2000, and shaders and the hardware they run on have all changed dramatically since then. Will shaders as we know them still exist in another 20 years? Would creating a game platform that relies on shaders make it difficult to adapt the same display API to newer graphics hardware that might use very different rendering tools? And then there's the question of, will anyone really want to write 3D games for the platform if it doesn't have shaders? If not, is there perhaps some other, more future-proof way to provide equivalent functionality?

Or maybe it's not even a problem that warrants so much concern. Maybe by the time modern shaders are no longer a well-supported way of displaying graphics, it won't be an unreasonable demand on the future's presumably more powerful CPU hardware to use software rendering for the same shaders.

And support to various gaming peripherals, multitaps, DK Bongos, Zapper, Steering Wheels....

I think you're trying to be sarcastic here, but actually no that's absolutely right. Another thing that I've thought a bit about is what an input API might look like if you want to make it possible for the game to be playable with keyboard, mouse, touch screen, controller, VR doohickeys and/or whatever else that hasn't been popularized yet, without having to go back and add in new input logic to old games.

[eyeliner]

No, I am not being sarcastic. If such a thing exists, and to succeed, game variation must be accounted for, not just your run-of-the-mill quirky platformer.