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?

Chechy Levas
  • 127
  • 3

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,039
  • 15
  • 15
  • I disagree. I have reasons for not using an order book. For example an agent selects an optimal offer, based on criteria in addition to price, such as proximity. I am primarily interested in the ECS aspects of the question. I could recast this question in a different context: simulation of a brokerless postal system. We have parcel senders and parcel receivers. Should the parcels belong to distinct entities or should the receivers have a component that is a list of parcels received? – Chechy Levas Jun 17 '20 at 12:32
  • @ChechyLevas But isn't that the exact same problem, just that every seller maintains their own order book? And the buyer just puts buy orders into the book of the seller they want to buy from? Personally, I avoid components that are lists of stuff and use entities that I can select. If I have a parcel, then my parcel would be an entity with sender and receiver, and if I want to know which parcels entity has sent I can just select all parcel-entities with that sender. With a bit of caching in a system to avoid having to re-scan all entities all the time this is lightning fast. – Polygnome Jun 18 '20 at 07:37
  • It would be a very small slice of the functionality of an order book; each seller would have an order book with one offer. Multiple people would be hitting that same offer and all would be satisfied until there is nothing left to sell, or there are no more buyers. What you say about avoiding lists of things makes sense to me. And your statement about being fast is reassuring, so I will give this a go. Thanks! – Chechy Levas Jun 18 '20 at 07:47