Before we begin there should be some existing knowledge in place, if you don't know the stuff below then just go read up on it (each heading a link you can click on to learn about it). You don't NEED to know all of this, but it will be VERY beneficial.

Inversion Of Control

This is about how your objects (generally classes) get their dependencies, this approach is used heavily throughout the codebase and means most of what the class needs is passed in via its constructor.

Dependency Injection

This is related to IoC and is basically a industry standard way of resolving dependencies for objects in a way that is flexible and highly configurable. If you have ever seen any code with bits like Bind<ISomething>().To<Something>() then that is DI configuration.

Reactive Extensions (RX)

This library tries to make use of the common ECS paradigm while making reactivity one of its big bonuses. If you are unsure about what rx is or how it can benefit your project then have a read into it, simply speaking its a push approach to data changing rather than a polling approach.

Intro to Unit Testing

If you have not done any unit testing, then its not the end of the world, you don't NEED to suddenly become a testing rockstar but part of the benefit of using this framework is it tries to keep your code highly testable, so if you want to make use of that benefit its worth knowing how.

Mocking in Unit Tests

Related to unit testing, it covers how you can provide mocked/fake implementations of dependencies to force your code to act a certain way and then confirm that it behaves as you expect.

WHAT IF I STILL NEED HELP OR HAVE QUESTIONS!??!

If you want to know more on the above topics then feel free to drop into our Discord Channel to discuss further or ask any questions.

You can use SystemsRx with an infrastructure layer or just by itself, but it is recommended to use the infrastructure if possible.

SystemsRx is more of a bare bones library which other libraries such as EcsRx builds on top of so while you can use this by itself you may want to look at the libraries that build on top of this layer.

Pre built infrastructure or not?

Out the box SystemsRx comes with a load of infrastructure classes which simplify setup, if you are happy to use that as a basis for setup then your job becomes a bit simpler.

There is also a whole section in these docs around the infrastructure and how to use the application and other classes within there in common scenarios.

YES I WANT ALL THE INFRASTRUCTURE PLX PLX

A wise choice so to start with its advised that you take:

• SystemsRx

• SystemsRx.Infrastructure

This will provide the basic classes for you to extend, however one fundamental piece of the puzzle is the DI abstraction layer. It doesn't really care which DI framework as it provides an interface for you to implement and then consume that in your own EcsRxApplication implementation.

So here are the main bits you need:

• Download a premade provider or implement IDependencyContainer for your DI framework of choice.

• Extend SystemsRxApplication implementation, providing it the DI container provider you wish to use

There are pre-made DI implementations for Ninject and Zenject so if you can use one of those on your platform GREAT! if not then just pick a DI framework of choice and implement your own handler for it (using the ninject one as an example to base it off).

So if you dont know what DI (Dependency Injection) is I recommend you go read this and this which will give you a quick overview on what IoC (Inversion of Control) and DI is and how you use it.

It is worth noting here that this is EXACTLY how the examples work in this project so its worth cracking them open to see how its all done, but the same principals can be applied to your own applications.

NOOOPE! I dont care for your design patterns sir, just let me get going

Ok captain, if you just want to get things going with minimum effort then I would just get the core lib and manually instantiate everything that is needed.

This is like the most bare bones setup I would advise:

public abstract class SystemsRxApplication
{
	public ISystemExecutor SystemExecutor { get; }
	public IEventSystem EventSystem { get; }
	public IUpdateScheduler UpdateScheduler { get; }

	protected EcsRxApplication()
	{
		// For sending events around
		EventSystem = new EventSystem(new MessageBroker());
	    
	    // Update scheduler for deciding when an *update* should happen
	    UpdateScheduler = new DefaultUpdateScheduler(); // 60 fps default
	
		// All system handlers for the system types you want to support
		var manualSystemHandler = new ManualSystemHandler(UpdateScheduler);
		var basicSystemHandler = new BasicSystemHandler();
		var reactToEventSystemHandler = new ReactToEventSystemHandler(EventSystem);

		var conventionalSystems = new List<IConventionalSystemHandler>
		{
			manualSystemHandler,
            basicSystemHandler,
            reactToEventSystemHandler
		};
		
		// The main executor which manages how systems are given information
		SystemExecutor = new SystemExecutor(conventionalSystems);
	}

	public abstract void StartApplication();
}

Then all you need to do is go:

public class HelloWorldExampleApplication : EcsRxApplication
{
	public override void StartApplication()
	{
		SystemExecutor.AddSystem(new SomeSystemHere());
	}
}

HUZZAH! you are now up and running and you can make your own conventions or design patterns around this.