1

I am exploring the ECS pattern and my pet project is a simulation of an economy where the primary mode of interaction between economic agents is a transaction. Some of these agents are market makers (they passively advertise offers to trade - sometimes called making a market). Some agents are market takers (they browse offers and decide which they want to trade with).

So an offer is a component of a market maker. This is clear to me. I have a system that governs the process of market makers setting offers.

Now I need a system that governs the process of market takers browsing the offers and "notifying" the market maker of their intention to trade. I call this notification a proposed_trade. At every tick of the main loop, multiple market takers may want to trade with the same market maker based on the same offer. The market maker will then accept the proposed_trades for as long as it has the resources to satisfy them, then reject them thereafter.

So how do I model this with an ECS? Some options:

  1. Each proposed_trade belongs to a distinct entity and references both the maker and the taker. There may be many relating to the same maker.
  2. Each maker has, as a component, a list of proposed_trades (like a buffer) and the takers just add to the list when they want to trade.

Are either of these considered more idiomatic or is the choice a matter of taste?

1 Answers1

1

This has surprisingly little to do with ECS and everything with how orders from an order book are fulfilled.

In a real market, you have buy orders and sell orders, which are both put into the order book. When a buy order matches a sell order, a sale happens. How matches are made differs a bit from exchange to exchange, but usually this happens on a first-come, first serve basis (Price/Time algorithm). Even if your ECS has ticks, you can still obey this FCFS order by storing the time of the order granular enough. Some exchanges do not use FCFS, but instead maximize throughput. This is important because not every order might allow partial fulfillment.

Some references you could and should consider:

Your order book can easily be a system in an ECS, with orders being entities themselves. In fact, making the order book itself a system makes it very easy to swap out the matchmaking algorithm - just swap the system out for another one.

Polygnome
  • 2,071
  • 15
  • 16