Best Practice

[Bodyclock-Games]

Hi All, Just to say I'm enjoying my time with Stride, great flexibility but a lot to learn. I have a question about best practice. I'm playing around with settings, startup and the processor concept which I guess is the S part of ECS? I'm adding and retrieving to the game settings to set up screen preferences. I have this code in a SystemSettingsProcessor:

namespace Bodyclock.Core.System
{
    internal class SystemConfigurationProcessor : EntityProcessor<SystemConfiguration>
    {
        protected override void OnEntityComponentAdding(Entity entity, [NotNull] SystemConfiguration component, [NotNull] SystemConfiguration data)
        {
            Game game = Services.GetService<IGame>() as Game;
            SystemSettings settings = Services.GetService<IGameSettingsService>()?.Settings.Configurations.Get<SystemSettings>()?? new();
            SetScreen(game, settings);
        }

        private void SetScreen(Game game, SystemSettings settings)
        {
            game.Window.IsMouseVisible = true;
            game.Window.AllowUserResizing = settings.AllowUserResizing;
            game.Window.FullscreenIsBorderlessWindow = settings.FullscreenIsBorderlessWindow;
            game.Window.IsBorderLess = settings.IsBorderless;
            game.Window.SetSize(new Int2(3840, 2160));
            game.Window.Position = new Int2(0, 0);
        }
    }
}

the component I add to a Boot entity in the editor.

My question is is this sort of configuration better done here:

namespace Test
{
    class TestApp
    {
        static void Main(string[] args)
        {
            using (var game = new Game())
            {
                //Configuration here?
                game.Run();
            }
        }
    }
}

[Eideren]

The window may not exist before the call to game.Run().
You can extend from the Game class, override GameBase.Initialize and set the window in that method.

[Doprez]

the big difference to the 2 approaches is how the settings are added. With the second option you dont need to remember to add a component somewhere in your scene. You can register a service to the Game so that something similar to the processor is still accessible and it will just be done for you regardless of scene changes.

public class CustomGame : Game
{
	protected override void Initialize()
	{
		base.Initialize();
		GraphicsDeviceManager.IsFullScreen = true;
		Services.AddService(SettingsClass);
	}
}

then you can access those settings with var settings = Services.GetSafeServiceAs<SettingsClass>(); in any EntityProcessor or ScriptComponent.

EntityProcessors for this would probably be overkill but it will work just fine AFAIK.

[Bodyclock-Games]

Thanks for the replies. I'll have a play around with the second approach.

[Bodyclock-Games]

Works well. So the idea of services is a scene independant method of persisting application wide data/functionality? I guess the biggest challenge for me with Stride (apart from being able to create a new project) has been understanding the philosophy behind the architecture. Seems very flexible but is something I need to understand how to use to best advantage.

[Doprez]

Yes, although you arent stopped from adding scene specific data to those services so you will have to watch out for that. The way I use Stride is a similar way I would structure a web API so I would add required services at runtime that are application wide, have controllers(EntityProcessors) scoped to specific functionality and I like to have all of my data in a seperate folder similar to how the C in ECS is maintained.

[Bodyclock-Games]

Thanks for the confirmation.