Author here. Thanks for reading this post. I had fun making this and thought the path that led me to this might be interesting for others.
I’m really interested in feedback and ideas on things I could improve and add. I found this really inspiring as it got me more into programming, discovering electronics, and 3d printing.
I have no desire to ever make this project commercial, but it’s been a great platform for me to learn and experiment new things so I’ll take any idea be it for the gameplay or purely technical. Some features I have in mind are:
- Multiplayer over bluetooth where one device is the ‘game-master’ running the exchange and can monitor and guide players while injecting events.
- Additional quoting algos such as pegging one side of the order book and fighting for position
- A tutorial and better UI. The game is hard to pick up for the first time and probably needs to be made more intuitive etc.
While all of this was made with no practical use in mind (there are a lot of markets and products, and you’d trade them in different ways, so you’d need a different game to speak to a volatility trader for example), some people I work with at various trading desks found it useful for interviews or as an introduction to the idea of market-making for junior people.
This is a really cool project. When I was at Unity, we had a team build a Westworld themed isometric Gameboy game that would let you monitor and admin k8s!
This is great, when I first started in trading in 2006 one of the traders actually used a Gravis gamepad to do click trading. I even remember conversations between devs debating about the latency of the human eye in order to make screen refresh decisions.
Also around the time the was a company called Trading Technologies that had a patent for click to trade on a GUI grid/order book and was suing everyone.
I heard they sued everyone who displayed the book a certain way. The best way, actually: a single column of prices, with bid quantities on one side of the prices in the bottom left and the asks on the top right.
This seemed to be why you had to organise it yourself to show it the "TT way" on any other system instead of having it out of the box.
this is true. they had patented DOM displays to extent other software has to pay royalties for static doms. quite stupid. the main thing was keeping price centered of all things
It's a tough question because most of what I learned was on the job and I don't really remember books specifically on the topic. It also depends on what product and market you are trading, and on what channels (on exchange, over the counter etc.)
I would say it starts with knowing the product you trade and their dynamics inside out. How to make a price for it, what dynamics can change that price etc. It's also a good idea to understand related instruments as typically you would use them for price formation and hedging [1][2].
The second bit is to understand electronic trading infrastructure and the market microstructure such as how orderbooks work, and some trading algos [3]
If you're also interested in the infrastructure behind related to low latency, you can read about FPGAs, Exchange co-location etc. There is a fascinating blog on the network infrastructure [4] and the author (Alexandre Laumonier) also wrote a few books on that topic.
A lot of market-making is bespoke and proprietary. For example your pricing model, hedging model, etc. It's also constantly changing depending on events (e.g. the elections) or market conditions (correlations changing). But a good place to start is to use some simple pricing model such as making a blend of other prices in other venues, or for derivatives making up the price based on the underlying price and other elements which vary depending on what the derivative is.
While you would not be able to gain direct market access to, say, the NYSE, a lot of crypto platforms offer APIs for users to build trading bots as a training ground. For example Bitmex, or Deribit. But before doing this I recommend understanding the contract mechanics inside out. For example, the perpetual futures have a very particular mechanism which means they are priced and traded differently than normal futures you'd read about in the Hull book.
I have a few friends who built bots and make small markets on random cryptos for fun. In this particular case, you'd have to think a bit harder on how you hedge your positions (e.g. can you sell an illiquid coin and hedge with a liquid one for cheap?). One way of doing this may be to look at correlations between coins to find the best hedge. Another consideration for crypto is the fee structure which you'd need to account for in your price.
I don't know if it's a good idea to start doing this in crypto besides for fun though, mostly because it's a business that requires scale to derive a meaningful profit. But as an exercise it's definitely fun.
[1]Options, Futures, and Other Derivatives (J. Hull)
[2]The handbook of fixed income securities (Frank J. Fabozzi, Mc Graw-Hill Gb)
There isn't any library for the trading UI or graphics elements. The only library in this case was the display graphics library which allows to draw simple primitives such as squares, lines, circles, text, etc. [1]
The UI is a bunch of elements you would see on various trading systems (orderbook, trade blotter, market depth chart, intraday rolling chart, scrolling news ticker etc). But they had to be implemented from scratch using these primitive shapes and coordinates on screen.
For example, the chart element is rendered by looping over the recent prices, calculating the min/max values to derive a range and adding a buffer on either side. Then calculating the price interval of each pixel (difference min-max divided by the number of pixels of my chart area). I then iterate over the prices, calculate their positions on the display in pixels, and draw series of lines between consecutive prices.
I'm afraid not because it would only run on the device so you'd need to make one using a raspberry pi pico and the exact same display (Pimoroni display pack) as it leverages its graphics library to draw text and shapes. So far, the only way I've been sharing this was by handing out devices as gifts with the game preloaded.
I recently started another version which runs on desktop using python/PyGame which I could package up and share and has very similar mechanics except it's faster-paced and intended to look and feel like a sensory-overload arcade game (sounds, lights, music, flashes, announcer voice etc). It's also a 2-player 'versus' game which can be played locally. The intent behind this was to build an arcade station around it, but it can be played on the computer directly using a keyboard.
It looks like this [1] but it's not yet in a playable state and would be hard to pick up as is. I'll continue working on it and then post a link to the github.
Hey, yes I can do that. I will brush this up, package all the bits (3d files, pcb files, code etc), and add to github.
On another note, would you happen to live in London? If you really want to try this I could hand you one which will save you plenty of time finding the parts, printing the case, ordering PCBs, and soldering. You can reach me on first_name dot last_name hat gmail dot come. The name is at the top of the original post.
Hey of course, happy to meet and exchange about our fun projects. You can send me an email using the address in the above comment and we'll setup something!
I’m really interested in feedback and ideas on things I could improve and add. I found this really inspiring as it got me more into programming, discovering electronics, and 3d printing.
I have no desire to ever make this project commercial, but it’s been a great platform for me to learn and experiment new things so I’ll take any idea be it for the gameplay or purely technical. Some features I have in mind are:
- Multiplayer over bluetooth where one device is the ‘game-master’ running the exchange and can monitor and guide players while injecting events.
- Additional quoting algos such as pegging one side of the order book and fighting for position
- A tutorial and better UI. The game is hard to pick up for the first time and probably needs to be made more intuitive etc.
While all of this was made with no practical use in mind (there are a lot of markets and products, and you’d trade them in different ways, so you’d need a different game to speak to a volatility trader for example), some people I work with at various trading desks found it useful for interviews or as an introduction to the idea of market-making for junior people.