I’d like to be able to call my own REST API to implement systems such as voting, analytics and global in-game events. Is it going to be possible in the future?
This is not currently possible, and there are no firm plans at the moment I’m afraid. This would obviously be challenging from a security and moderation perspective, for example.
Roblox has this capability. We should have it, too. Please reconsider this one and please make it a priority. There is so much we can do with this capability.
1 Like
Hey, I’m curious what would be the worst thing that could happen from adding HTTP Request support? Roblox has a limit of 500 request per minute per server so it can’t be used for any specific illegal activities. And Roblox has blocked any and all requests to their own domains, I can’t think of ANY possible security issues if those two measurements are implemented.
You could, for example, circumvent the moderation processes (for disallowed content or monetization)
You should just let us only call GET requests than at the very least, I can understand the possibility of bypassing monetization, however, but I do not understand how we might bypass the disallowed content.
Why not simply allow HTTP requests if they are validated developers through the Epic Online Services portal? Making it require coming from the same domain.
1 Like
Thank you for the feedback, I will pass it on to the team.
1 Like
Oh, this is an Epic fail. Seriously, there is nothing open or interoperable about this decision. This is a walled-garden mentality and frankly an innovation killer. Not being able to integrate functionality that exists outside the Fortnite fortress walls means that Fortnite will not give creators the ability to use the most important interactive innovations - generative AI. Look at services like inworld - that is a critical piece for more engaging experiences.
Furthermore, it has a negative knock-on effect on the economy. With creators not able to bring in functionality that exists outside the Fortnite system, Epic then owns the “means of production”. Epic can build whatever features suit themselves, Creators just have to live with the functionality they are given.
Look around at all the advances in LLM’s being used as coding assistants (Codex, Copilot) the need to “eliminate runtime errors” and the “security” bogeyman are antiquated ideas. Then look at what Rust has to offer. Do you really need to invent a new language? If @Tim_Sweeney is going to look back to Pascal for syntax examples, why not look back to Anders Hejlsberg who made Pascal usable with Delphi and then went on to design C#.
Please, please reconsider. Make the system smarter. Make the system easier. Make the system approachable.
Please DO NOT force a new language with a unique, perhaps innovative structure on people. Millions and millions of people have spent a tremendous amount of time and effort learning procedural languages. They make sense to people who are not about “math”. I understand the challenges that dynamic languages pose at an analysis level, I would happily give up dynamic features.
On the syntax level, if you want to do something that is accessible and easy to learn, you should look back to SmallTalk. If you are going to build a virtual world, you really should have syntax that models the real world.
Honestly, the whole world is being turned upside-down by LLM’s. Writing code is being revolutionized - and the revolution is not functional syntax. The future of coding is natural language based. Put your effort into getting things at the compiler level, don’t push the hard work on the creators.
Here is another example. Look at the success of Visual Studio Code. Would it have been successful if you could not bring in functionality from the outside. A world without Codex (from OpenAI) and there would be no competition for Copilot (from GitHub). You need to have competition for functionality/capability.
At the end of the day, it is all about the INTEROP. Without Interoperability, you will never, ever build an ecosystem that will thrive. Without Interoperability you are, by definition, creating a walled garden.
I look forward to continuing this conversation here on the forums and out in the open.
Sincerely yours from a real believer in the rest of the Epic metaverse vision - and a massive fan or Unreal Engine (full version) as one of the most empowering creative force in the world today.
4 Likes
@Dig_Squid - would appreciate your thoughts or your colleagues.
Thanks very much for your feedback, I have passed it on. There is a lot to think about there, I do agree that generative AI is a hugely important topic.
1 Like
Agreed that Fortnite Creative 2.0 is basically a walled garden right now. It’s open for UGC which is nice, and they’re cutting us in which is nice, but it’s still a walled garden.
I think I understand why now, though. Epic’s intention is to foster the “open metaverse” as per State of Unreal '23 and multiple interviews but it’s not quite clear yet (to them or to us) how that’s going to happen.
In other words, we’re still in the early days and we’re along for the ride.
Tim Sweeney recently said “no” here when asked if NFTs would be implemented in Fortnite Creative 2.0 (original post/question since deleted). But he previously implied it was a possibility during State of Unreal '23. So, I’m taking it as a no for now.
I also saw a comment from @Dig_Squid here that one of the reasons for not giving us REST functionality is that it would allow us to “circumvent the moderation processes (for disallowed content or monetization).”
By the way, one thing to take note of that was not explicitly called out by @Dig_Squid is that because Fortnite is available across almost every platform, and each platform has varying monetization policies, I think we’ve so far ended up with the least common denominator. Were Fortnite to allow UGC to bypass these policies, they (Epic) would be liable and it could get Fortnite in hot water with the platform owners.
1 Like
thanks so much @Dig_Squid
Here is an article that sheds some light on their outlook on the metaverse and their current strategy:
Tim said over and over, no walled gardens. He also said Interoperable and Open. End of story. Either it is open and not a walled garden or it is not. No access to APIs outside the “Fortnite” system is, by definition, a closed system. Moderation policies are not compromised. There is plenty that can be implemented at runtime to keep an eye on that. Finally, being able to circumvent the Monetization system is part and parcel of an open and interoperable (not a walled garden) environment. I mean come on, after all the fighting with the Apple AppStore, I find it curious that Epic “require” that all apps participate in the nacent Fortnite Economy outlined by Tim.
The aim is to get from here towards the open metaverse along an incremental path that respects privacy rights and privacy laws around the world, and doesn’t retrace the steps that made the open web a fiasco in this regard and are putting Roblox on a shaky foundation.
The next step we’re working on right now is a system to provide simple but useful persistence soon that doesn’t expose private player information to external web servers, designed to be player friendly and respect the relevant laws around private information, deletion requests, and so on. Over time this can evolve into an open spec for federated persistence across different services, built on top of OpenAuth and various data privacy standards. (Our account system already OAuths with PlayStation, Nintendo, Xbox, Android, Steam, Google, and Apple, and we’re working towards a federated approach.)
The long term aim for persistence isn’t the wild west of everyone sending player data to servers around the world, but that it’s built on the foundation of automatically persisting the contents of Verse data structures and making them accessible (live) across different game sessions, with sensitive built-in data types such as players designed to protect privacy with respect to federation boundaries, without complicating user-made data structures.
9 Likes
If you want to make API calls to servers around the world, why not run Unreal Engine on your own server?
It seems like you want UEFN to be something it’s not. There is room in an ecosystem for both walled garden spaces and fully open hosting style. Maybe some people want to play games within a closed platform where they know their activity isn’t being sent off to servers in China, or Russia, or who knows where?
Even if you prevent images and files from being downloaded with these requests, what happens when your external server goes down and your game starts throwing errors–this makes Fortnite Creative look bad and they will probably get support calls.
I understand why Epic is creating this as a more controlled space and I think there is a place for it among everything else.
2 Likes
@Tim_Sweeney I really appreciate the thoughtful reply. I do believe that there needs to be an ongoing discussion between Epic and the Creators on fundamental aspects like this. I totally get that you are taking an incremental approach and I whole-heartedly support that. I trust that Epic/UE will continue to put awesome tools in every creators hands. The actions over the past 18 months makes me certain of this.
There are 2 issues I am concerned about.
Verse and Language accessibility
What I am concerned about is putting too much plumbing into the creator workflow. Verse is tough. I really wish we were looking backwards a bit when designing a language for regular folks. Alan Kay shares amazing insights on the Smalltalk journey here - The Early History Of Smalltalk Free the users/creators from being saddled with a language that is non-obvious and hard to read. The Kay paper has some excellent examples.
2. Calling Outside APIs
I am coming to this with the perspective of a creator who has been using UE. I have come to rely on the innovations made by members of the ecosystem. I look at systems like PlayFab and inworld. PlayFab being a battle tested back end, certainly up to the load. Second would be the emerging offerings like inworld which give creators incredible power. My hope is that use of these two an many in between will be possible.
At the end of the day Tim, I laud your efforts to avoid the mistakes made in the recent past. I also firmly stand by the ethos of “rough consensus and running code”. Your code is running, let’s get to rough consensus. Without getting the creators productive on the platform, I fear the explosive growth will be greatly tempered.
Once again, thanks for taking the time. It shows you really care.
1 Like
I’d also love the ability to make external REST calls and, to take it one step further!!, even make Websocket requests. I’m working on a simple web based game that’s strictly UI, but it’d be super awesome to integrate into the FN ecosystem and playerbase using UEFN and create a 3D world that builds on top of what can be played in-browser.
1 Like
Is there an update on this topic? I agree that it’s a pretty important feature to be able to make external API calls.