TheTank

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.

I drafted another version of this game which is more arcade-based (and does not run on handheld but a computer or arcade box) and the game is essentially about fighting over an orderbook to (a) be in the best position possible to capture the flow that you want, (b) monitoring for orders with a positive edge and sniping them faster than the other player (or even pick off the other player before they have a chance to move). The values next to the bid and ask quantities are the edge in basis points relative to faire value. If you see some positive edge somewhere you want to go and cross the book to pick out the price.

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)

[3]Algorithmic Trading & DMA (B. Johnson)

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.

The main value proposition is raw performance which translates into hardware efficiency and ultimately, costs at scale.

To get a rough idea of how we compare, you could try to running `select cab_type, count() from trips` and `select passenger_count, avg(total_amount) from trips`. They are the equivalent of queries (1) and (2) of this benchmark [1]. In this benchmark, BigQuery took 2 seconds for each query.

Our server runs both in hundreds of milliseconds. And this is actually slow because this is the same server which is currently being hammered by HN users. Also, we are scanning more rows. Our dataset contains 1.6 billion rows while the benchmark attached runs on 1.1 billion. Lastly, we only use one 24-core CPU from one server while the top of this benchmark is clusters or GPUs.

Of course this is only approximation but I hope to be given the chance to feature in this benchmark when we are ready.