openengine

OpenEngine

Football match engine

This should be the final attempt (of many) in creating an open source football match engine. The reason for so many previous attempts (you can see them by browsing this account) was more indecisiveness and starting over with a fresh approach rather than objective ‘failure’. Also I have been too ambitious with the potential outcome. As of lately, I have decided to take it easy, without ever abandoning this project as a concept.

I will do my best to incorporate as many potential approaches possible in an incremental fashion. Starting simple without any particular expectations will do the trick in making this project the “final” edition of something that I decided to pursue as early as 2003. The most conceptually representative project in this repository is openfootie. I will be doing some archaeology from time to time for either code or ‘ideas’ reuse. Some of these projects might also be resurrected. But in all fairness, I should have a definitive edition just for purity’s sake: an open source football match engine, “pluggable” to host applications, with the latter being a big feature/added bonus than the raison d’être.

The motto of this engine shall be this: don’t fake output. There should be consistency in how the input (players as “agents”, carrying the AI and relative attribute values, along with the team tactics) produces the output (whether that would be a 3D representation of the football match or just a plain score). Making this input - output mapping as realistic as possible should be the ultimate goal. But whatever abstraction we apply, the underlying concept should be that of consistency.

Latest update

After a while, I am resuming this project, but in a private repository this time. My goal at this time is that there will be less experiments, and I will be, in turn, more productive. When it looks at least like an MVP, I will start making my updates public. I hope that it will soon take the shape I am imagining. Because I already thought of a name.

Update

Revisiting what I wrote in the beginning of this project, I am a bit surprised to see that my opinions and impressions have not shifted much since then. Surprised because this project at least conceptually has matured, and now I have a much clearer idea about the next steps and stages, along with its limitations. And with this comes a better appreciation of the challenges of this project (which were always known anyway). The difference lies in the chasm between the idea of an ideal football match engine and a ‘good enough’ prototype, with the latter being the basis toward the former. It seems now, that not only is there a chasm but also a conflict between the two, if not regarding implementation, surely in terms of time and project management. For there are no shortcuts and MVPs when you are scratching your own itch.

A little review of where this project is now, in comparison to how it started. The original legacy project openfootie (which itself had evolved from previous attempts) was based on the idea of simulating player actions evaluating their outcome. The problem with that approach (apart from the sketchy implementation) was that it lacked the context in the implementation of each match event. The only parameter for ‘deciding’ on an action was a player’s position, while the rest of parameters were added as an afterthought. Also the outcomes’ evaluation should also depend on the context, and this also would be added as an afterthought, especially for having tactics influencing outcomes.

What do I mean by ‘afterthought’? The way a player makes decisions and the match is reproduced in general is data-driven. We generate different football matches, by essentially reshuffling the data. Since we only use and need a very small sample of even of one match half to generate the data, if we would like to be blindly faithful to the data we would miss a lot of real world scenarios or overemphasize others. One solution to this would be a big enough sample, or more easily and quickly, we could intervene in the engine logic and adjust it to include more real world scenarios. As a side-note this is my latest addition to this project: mapping goal attempts to expected goals (xG), I can make the outcomes vary, rather than use the ones fixed on the data itself.

So, in this incarnation of the project, my goal has been to make it as much data-driven as possible, including potentially needed context parameters, leaving little room for (ad-hoc) interventions in the match engine’s logic. In this respect, context is not only the player’s (having possession of the ball) position on the pitch, but also the phase of the match and all other players’ positions. A tracking data based engine more or less.

You understand now how time-consuming that is. In the long run, codifying and interpreting the tracking data would be automated, but my approach is to start and continue small and menially, for fully appreciating the next steps and directions.

Another approach would be to still make an MVP (or many) based on what we have so far, making assumptions and creating plausible results. The project, I think, is now robust enough to allow for such deviations and interventions, while still remaining honest to its conception.

In conclusion, the OpenEngine project is nothing more than an umbrella or ‘meta’-project for the different approaches one could take on creating a match engine, with the data-driven approach as basis being more conscious and intentional than in the legacy openfootie project.

I may be providing a few updates on this with my thoughts as I will be continuing with the next stages of this project. Now on a more technical review on its current stage: one thing I had also got wrong not only on the original project, but also until lately is that roughly-speaking the level of detail between input and output should be the same. For example, I would apply either a top-down approach or a bottom-up one and that should reflect on both the input and output. Examples: a top-down approach would be to have the teams as inputs (even as minimal as Elo rankings) and only the match score as output. A very extreme example, as technically this would not be an engine, but we could have elaborated on that to make it at least look like an engine (by producing more stats). On the other hand, we could provide a lot more information as input (regarding tactics and player attributes), and expect full tracking data, with the match being able to be replayed visually. However, apart from not being necessary that input and output match at the level of sophistication, it also gives us flexibility in applying different approaches for the further development of the engine. At this stage of the project, I use a ‘bottom-up’ input, which is the data itself (notice that I split the match data according to team possession, serving as each team’s input, except that instead of providing tactics and ‘attributes’, I am providing raw match data), while the output is ‘top-down’, as we only see a sequence of events abstracted at the ‘team level’ (so much that we wouldn’t for example extract reliable statistics). However, this very abstracted approach is very flexible, as we could go higher or lower-level without the input being tightly-bound on the output, or for that matter, being concerned at this stage with what a ‘complete’ match engine would look like.