Open sanbox-irl opened 4 years ago
@dlight: What about developers who do not want to do any porting, and just want their existing (portable) code to Just Work? For instance, some game devs might not be willing or able to sign NDAs.
If you won't sign a console's NDA you can't publish your game on the console. These are closed platforms, you have to play along with the rules of the platform owners or you can't get anywhere.
Most publishers claims copryight for your game to release it on consoles when you cannot sign NDAs.
If you won't sign a console's NDA you can't publish your game on the console. These are closed platforms, you have to play along with the rules of the platform owners or you can't get anywhere.
On that note, any shipped title goes through a certification process. The primary blocker here isn’t technical. It’s convincing first parties that supporting Rust officially and maintaining tooling for it is worth it to them. Or potentially having a game they want on their platform badly enough to be willing to waive certain certification requirements.
One exception here might be wasm - as long as the interpreter isn’t JITing and is compiled via a certified path, I expect they would not object to it. And of course tools that do not ship in the end-product.
If you won't sign a console's NDA you can't publish your game on the console. These are closed platforms, you have to play along with the rules of the platform owners or you can't get anywhere.
I’m mostly thinking of games that are open source or are run by people who have other jobs. My understanding (from this thread) is that the latter prevents one from signing an NDA, and the former makes signing an NDA risky. Even if one has all of the console-specific code in a downstream fork, there could still be legal risks. Hence the desire to be able to treat the console as a black box, hidden behind console-specific forks of libraries that are API-compatible with the open ones. That allows one to develop exclusively against an open API.
While signing NDA, they expect you to not work for any tech oriented company. As part of any studio, you cannot become a partner with Sony, Microsoft and Nintendo, unless you are self-employed director which is what I do right now.
Your previous workplace can be questionable for them too. Like if you worked for Sony, Apple, Google or whatever then e.g. Nintendo can then take off your license without notifying you even.
I’m mostly thinking of games that are open source or are run by people who have other jobs.
Those sorts of games just aren't going to end up on a closed platform. If you want a completely open API then perhaps the homebrew path could be a way to get your game on a console, but there are not open routes to official game development on consoles. That's just the reality of the situation.
I’m mostly thinking of games that are open source or are run by people who have other jobs.
Those sorts of games just aren't going to end up on a closed platform. If you want a completely open API then perhaps the homebrew path could be a way to get your game on a console, but there are not open routes to official game development on consoles. That's just the reality of the situation.
Hence why I was suggesting that there might be a route where someone writes an open game against open APIs, and someone else builds it against a closed implementation of these APIs. Is there something that prevents this from working, and if so, what is it?
Hence why I was suggesting that there might be a route where someone writes an open game against open APIs, and someone else builds it against a closed implementation of these APIs. Is there something that prevents this from working, and if so, what is it?
Licensing (most open games are GPL/AGPL), high costs and that, if you want it to be published by someone else, you still need a company to be pointed as original developer of the game unless you will allow them to claim copyright and publish as their own product.
There is a target for nintendo switch, but apparently it's for homebrew: aarch64-nintendo-switch-freestanding
There is a target for nintendo switch, but apparently it's for homebrew: aarch64-nintendo-switch-freestanding
Thats first step to upstream std for homebrew.
Hence why I was suggesting that there might be a route where someone writes an open game against open APIs, and someone else builds it against a closed implementation of these APIs. Is there something that prevents this from working, and if so, what is it?
There is a confirmed Switch port of SDL2. https://twitter.com/icculus/status/981730137736712192
I have not found any information about SDL2 for Microsoft or Sony consoles. SDL2 for the Panic Playdate is a work in progress. In theory Rust bindings to SDL2 could be used. https://devforum.play.date/t/sdl2-drivers-for-playdate-yes/4060
NDAs prevent talking about specific details in public, but the Playdate is an open platform. Playdate specifics can be used as an analogy for the kinds of quirky platform details console throw at developers. For example, IIRC Playdate does not have a standard libc. It has a propriety sorta libc with things like platform specific functions for printing instead of a normal printf. Game also need to be written as an event handler and an update function instead of a standard game loop.
A while back, I started a Rust thread on the official development forums of one of the major game platforms. Feel free to join in the discussion there if you are behind the NDA-wall.
I have not found any information about SDL2 for Microsoft or Sony consoles.
FNA (which is developed by one of the SDL2 maintainers, and has a very strict policy about keeping platform code entirely in SDL2 rather than in the framework itself) does support Xbox, and has Playstation support in development, according to https://github.com/FNA-XNA/FNA/wiki/Appendix-B:-FNA-on-Consoles. So I think it is a fairly safe bet that SDL will work on these platforms in the not-too-distant future.
Maybe it is best to only interact with the OS via SDL2 if one wants to support consoles.
First, you need SDL2 bindings which are not few versions behind to easly swap the source code for e.g. Switch. But then you won't be able to release your game on PS5 because of Sony's licensing which makes it impossible to legally release rust game.
EDIT: Few weeks ago talked with FNA maintainer about support for consoles and they said, there are many technical issues, mostly with FAudio, they suggested to stick with Rust for my game instead. C# is even more hacky becuse you need to compile dotnet IL into C++.
I'm currently working on upstream xbox support in winit, starting from gamepad support on windows. Compiler licensing team also allowed merging Xbox Series X|S as new backend in compiler unless there will be needed some NDA code to fully compile binary with some special msvc version or GDK in std etc..
If Sony makes it legally impossible to release Rust on PS5 why does that make a difference for using SDL2 on the Switch?
In general, using the "system" SDL2 is pretty simple. I was able to update the fermium
build script to support that in about half an hour.
If Sony makes it legally impossible to release Rust on PS5 why does that make a difference for using SDL2 on the Switch?
Sony just have some special licensing which I cannot discuss here but in general other consoles don't really care about language used.
Sure, I get the NDA stuff. I don't need you to discuss it. My point is that if they're going to say "no" regardless of what you do, then forget about them and focus on consoles that will work.
@HeavyRain266 Being intentionally vague because this is a public forum, but I suggest you search the internal site for "R5085 rust" and see the related material.
Hi there,
I'd like to help get Rust onto Consoles more. I have two devkits from the major platform holders (I'm trying to be a little subtle here to avoid breaking any NDAs) and have signed an NDA with the third.
I have tried at work to get others onto using Rust in gamedev, but the hardstop, for the kinds of games I work in, is console support. If you've ever wondered why Godot seems to have so little traction, a lot of it is a lack of console support. Every conversation about Godot, and, unfortunately, Rust, starts with "wow I love this" and ends with "pity I can't easily get it to run on consoles."
I think we would all agree, however, that Rust is excellent for gamedev, and it would be great to code less in C++. However, to even get to that point, we need to build some infrastructure. I think this would be in the purview of the WG and would love to discuss that with some of you. I imagine this would take the form of a private repository managed by the WG which requires an invite, predicated on demonstration of an NDA signed, to join. I would be very willing to help with that. It would be easier to talk about this over voice and in a less written way of course.
Getting that infrastructure down first allows us to tackle the actual code issues necessary for console support.
Let me know what you guys things