Quoting: mborse

Quoting: soulsource

Quoting: Dribbleondo

Quoting: soulsource

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.

Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell [External Link].
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

Our general workflow has changed in the last few years. Initially we did prototype a lot of things in Blueprint with the goal to move the whole logic to C++ later for performance (nativising Blueprints was not supported back then), but found out that more often than not those "prototype" blueprints remain in the project until release for time reasons. This was an actual problem in Bus Simulator 18, when we added gamepad support later, because that required understanding very complex UI blueprints... Also, everyone who tried to make a bus mod for Bus Simulator 18 [External Link] knows that the bus blueprint setup was - let's just say I'm surprised nobody posted our bus base blueprint on Blueprints From Hell.

Since Bus Simulator 21 we try to do almost everything in C++, including prototypes. The main reason is readability and modularity, with performance being an added benefit. Emphasis on "try", because in BS21 some logic still happens in blueprints, and there are exceptions like the mission system. For the UI we added our own "framework" of sorts, where we back up most UI blueprints with a ViewModel on the C++ side, so that the view blueprint only needs to display the data computed by the view model and update itself when the respective event is triggered on the C++ side. For the missions the main reason to use blueprint was iteration times for designers when setting them up in-editor, but we also offer the option to create missions for map mods in BS21 [External Link], and all our modding support runs through blueprint.
What made prototyping in C++ viable was the addition of Live++ to Unreal. Though still some limitations apply on what can be done without an editor restart, this tool made iteration times for C++ changes nearly comparable to iteration times for blueprint changes.

The criteria when we moved code in BS18 from Blueprint to C++ were usually one of these two: Either we happened to have to modify some blueprint and it had already "grown organically" until it was utterly unreadable (so moving it over to C++ was synonymous with understanding what it does), or we found out during profiling that some code path in a blueprint was causing performance issues.

In Bus Sim 21 the first reason basically did not happen, because of the goal to also prototype in C++, but the second reason, performance, was still encountered quite often in late-game missions. (The Mission Helpers blueprint function library one can see in the mod kit is the result of that.)

Long story short: Both, neatness and reusability play a role for our decisions what to do in C++, with nowadays nearly all development happening in C++.

View this comment - View article - View full comments

Wait, so their servers don't validate client data?

Reminds me of the xkcd Exploits of a Mom [External Link]...

View this comment - View article - View full comments

The art style reminds me of my wife's ink drawings. I'm definitely going to buy this game.

View this comment - View article - View full comments

Quoting: Dribbleondo

Quoting: soulsource

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.

Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell [External Link].
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

View this comment - View article - View full comments

Quoting: mborse

Quoting: soulsource

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

I was thinking about the same, but have a bit of frustrations with (custom) forks since UE development occurs so fast that i was bitten more than once by breaking changes in the APIs, even with what were supposed to be small point releases. Lighting and shading, BxDFs in particular come to mind. But back to the discussion, the lack of binary releases for UE is a non-issue since the target users are developers anyway.

Yeah, I've just yesterday had a similar experience with some custom optimizations in decal rendering, that we (for the moment) decided not to merge into our UE5 projects, because it would require non-trivial manual merging...

In general we are trying to stay as close to upstream as possible in our project-specific engine forks. Most of our changes are backporting some fixes from newer engine versions, or fixing some issue inside a function. We try not to change any public APIs if possible. If something can easily be fixed or worked around on the project side, we strongly prefer that approach, going as far as duplicating engine classes in-project if it makes sense (for instance we have our own modified copy of TOctree2).
The one area inside the engine that we do modify heavily per-project are the online subsystems. Our multiplayer use cases are significantly different from what Epic needs for their games, therefore we usually have to add some features to multiplayer session handling functions (just as an example, we need to update session metadata while the session is running and forward that change to all players in the session, what is not fully supported out of the box by some online subsystems)...

View this comment - View article - View full comments

Good.
There are imho two kinds of people who want NFTs in games: Publishers who want to scam gamers by making unfullfillable claims about the potentials of the technology, and gamers who do not understand the technology and therefore fall for the empty promises of those publishers.

View this comment - View article - View full comments

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

View this comment - View article - View full comments

Quoting: levellordIs it suitable for kids? I am sure my 9 year old will ask for it the moment she learn about it. Thanks!

I've just played for about an hour, but from what I've seen up to now I'd say it is.
There are some robot "rats" (for lack of a better word) that attack you, so there's some action, but there was no visible brutality. All that happens if such an enemy catches you is that it clings to your character and you have to shake it off by pressing a button.

However, the game is actually rated by the USK, as "Approved for children aged 12 and above" (description of age categories [External Link], what might be a better guideline than my personal gut feeling :tongue:.

Edit: It also has an ESRB rating, and that one is ESRB-E 10+. (Description [External Link]
Edit 2: Source for Ratings is the PlayStation store. USK is shown if you visit the German store, ESRB if you visit the US store.

View this comment - View article - View full comments

Computer games in a car... What could possibly go wrong?

(Edit: Just to be clear, I'm joking. I'm expecting them to prevent access to games while driving.)

View this comment - View article - View full comments

Quoting: DemandredDiscovering this community since I got my steam deck. Thanks for this site !
Noob question, all games that run on the steam deck would work on a linux pc as well? Shall I jump into a linux experiment.... wait I just did. first time on a linux desktop to install the emulation on the deck.

While the general answer is "yes", there are some things to keep in mind when dealing with Windows-games running through Proton:

• Graphics drivers. The open source AMD Linux drivers and the closed source nVidia Linux drivers have some edge cases under which they behave differently. The most important one is the situation that a game runs out of video memory. In the case of the AMD open source drivers, that will lead to a performance drop because system memory is used as a fallback. With nVidia's closed source drivers, the game will crash. This means that if you have an nVidia card, some games might not work on the desktop that are working fine on the Deck (which uses the AMD open source drivers).
• There are some subtle differences between Deck and desktop when it comes to video playback, that I haven't fully understood yet. It might be that you need to install GE-Proton [External Link] on the desktop to get videos running in some games. I'd still try Valve's official Proton builds first, but if those fail to play videos, GE-Proton might get them working.
• For some titles Valve considers important, there might be Steam Deck specific fixes.

Long story short, the best experience on Linux is still offered by games that have a native Linux build, but Proton can get a lot of Windows games running too.
I'd recommend to check protondb [External Link] for Windows-only games you care about, especially if you are using an nVidia graphics card (-> check the GPU the users reporting failure/success were using).

View this comment - View article - View full comments