Event handlers and interaction with outer world

[DigitalSmile]

Usually the economy simulation is the part of bigger project (game, scientific efforts, etc.). It should have more clear API and provide endpoints/handlers to interact with.
I would suggest to start with handlers that can inform subscriber about events occurred during simulation. My candidate is https://github.com/greenrobot/EventBus as it is lightweight and fast.

[guillaume-alvarez]

I dont think you should include the event bus in the API. The event bus (or any other threading model) should be up to the user.

However the API could provide POJO events and methods that can be used with most use cases.

[DigitalSmile]

That is a good point. However, it's not only about providing POJO classes, but also create a process of getting notifications. Any ideas how we can go with handlers registration API?

[guillaume-alvarez]

Something like addListener(Consumer<MyEvent>) ?
Then you just need an CopyOnWriteArrayList<Consumer> with synchronization on public methods.

Another possibility is not to publish events be instead do like most physics engine with a tick/update method and a public state that can be fully inspected by the application.

[DigitalSmile]

Yes, I forgot about functional interfaces in java... I guess it makes sense to use Consumer interfaces. Thanks for the tip.
As for the gaming development, I am no very familiar with architecture concepts of gaming engines... So it seems you can have god object with app state, that updates each tick/step?

[DigitalSmile]

@guillaume-alvarez I wrote a quick prototype here https://github.com/JeremyWildsmith/bazaarbot-java/tree/events
Does it make sense to continue this effort in terms of your needs?

[guillaume-alvarez]

I'm not sure how the simulation is progressing right now, you start it in a thread and then it occupies it until it run for n turns?

[DigitalSmile]

You can run it with 3 type of runners: DurationBasedRunner, FixedRateBasedRunner and RoundBasedRunner. All three can run sync or async (in different thread) depending on how you are calling Bazaar class.
You can find the example in tests.

[guillaume-alvarez]

I can think of two different use cases:

• generate a simulation of a an economy then provide all the data => it seems it is the main use case as of now
• integrated in a game as an economic engine to compute goods prices over time (would make sense in a RPG or simulation or strategy game) => the game designer must be able to make the simulation progress at will (every frame ? every second ? every time the player clicks on the "End Turn" button ?)

In the second use cases, events listeners may not be very useful, it would be better to access a list of events since the last 'tick' and the current price/money of every good/agent.

[JeremyWildsmith]

Hello, just dropping my opinion in here.

If there is any interfacing with Bazaar bot, I think it should be in-between rounds (frames of simulation.)

In that case, any API interaction should occur in-between these frames. At the end of each frame, we can return a record of all processed events. I think that is by far the simplest solution.

I think callbacks / listeners get pretty tricky pretty quick (especially if they occur during the simulation of the frame, since interaction during frame simulation would be prohibited anyways.)

In summary: I think simulation should be in small increments (frames / steps / rounds) and inbetween these increments we open the simulation for interaction from external API. Or, we open the actions performed to analysis to external API - but only inbetween frame simulation (ie, after or before a frame is simulated.)

[DigitalSmile]

So, in other words we can collect the events during simulation step/frame and only after that fire corresponding handlers?
This discussion makes me feel pub/sub approach cannot be used here as handlers themselves could be heavy performance wise (because of its user-defined nature).

[DigitalSmile]

In addition: we have Statistics object that is holding all historic records of every and each deals in immutable state. It can be used to query any data/events you may possibly have. The only thing is missing having a mutex, while step/frame is on the way.

[guillaume-alvarez]

In a game,

• either you make the simulation progress at every frame/turn, so it is executed in the main frame
• or you make it progress in another thread, with custom synchronization to ensure it is in line with the other parts

In both case the synchronization is the main dev job, not done by the library. So I would say there is no need for a mutex.

I agree that pub/sub is not very useful in that context, it is much easier to use if able to access the data whenever it is needed.

[DigitalSmile]

So I tried to refactor the current approach and provide the outside world with statistics helper (which can work with provided market). Can someone please review?