atas76 / openengine Goto Github PK

There are quite a few fields in a DynamicTransition, especially in the constructor. Maybe we need some defaults (with null value), for those fields whose value is going to be calculated dynamically. One other design decision is whether to create a copy constructor from the Statement object in order to avoid having numerous parameters in the constructor.

Having a flag for goals (from successful attempts) is probably redundant and a proven source of bugs. For example, we opted to use an intermediate GOAL_ATTEMPT_OUTCOME state as a result of the dynamic calculation of goal attempts outcomes, instead of a flag. Rather for using a flag for goals - for consistency among other things - we should just update the end state of the transition and take only transitions with GOAL_ATTEMPT_OUTCOME as initial state into account for counting goals (as we have to do anyway, it is just we won't need to refer to a redundant flag).

For competition matches, and in general, we need to add home advantage as parameter in our calculations. For competition matches, this will also need to be applied according to the competition rules (e.g. for FA Cup, applied only in rounds prior to the semi final).

Using just the match phase states for chaining transitions is a handy hack, however for both realism and accuracy we should be also using the pitch positions as reference. This was anyway the next step in the previous incarnation of this approach. One interesting thing to check is whether we have overfitting, with the low amount of seed data.

We need to achieve a minimal sampling of matches, with the goal (no pun intended) to have a valid sample of goal attempts fully covered, in order to build additional samples on top of that from summary data (#3)

Currenty, in the latest edition of the data tracking language (TTN - Tactical Tracking Notation) the match data are broadly under two categories: statements and directives. Statements describe what in football analytics is called 'match events'. Directives, while descriptive in themselves, cover many different metadata categories, and these categories should be distinguished further. The only way that this could be done at this point is with application logic (a naming convention was actually added to distinguish one particular category), which is far for optimal. First, the different categories should be identified and documented, and then changes in syntax (and/or new keywords) will be introduced to reflect the different categories.

In the future, we will need a field to describe not only goal attempt outcomes, but also 'final state' outcomes in general.

Probably, we start with goals/chances first, and work our way deeper. Calculation on individual players skills and match tactics will be handled later. Maybe, we also go for separation of skills, collectively per team, rather than collective ability per player (realism over plausability, again).

Hey name is Mitchell and I am a BIG soccer fan. I've always dreamed of building my own Soccer Maagement Simulator (like Top Eleven and the likes) but I don't really know where to start. How did you learn to create such a system? Do you mind sharing any resources you used to get to this point? Amazing work!

Currently, I have some (commented-out) System.out-s for debugging. A more proper way (and not for debugging only) to log match events would be to output to a default file. We also need to decide what format the logs would be. Maybe, in the future create also a file for outputting match summary report, but for displaying the score the console is sufficient at the moment.

Have to be careful to take into account when match flow "breaks". The simulator will fail on runtime if this happens, but maybe would be a good idea to have a check on that, for when the data or the code get more complicated.

It'd be nice to have a brief introduction at the README.md explaining how to install & run this project. This will help any potential contributor to dive into the code & mechanics and push this project even further.

I personally don't know how to compile it, otherwise I'd create a PR with the instructions.

For simplicity, we currently implement the knockout matches tiebreakers with a 'coin toss' simulation. Proper tiebreakers (extra time + penalty shoot-out) are going to be implemented next for knockout competition matches.

A first step towards fixing the issues raised in #39 is to write clear commentary which will help immensely at initial debugging stages and sanity checks, while the output itself would make more sense from a "user's" perspective.

This is mostly for statistical purposes rather than actual testing (hopefully, but looks good so far): run the FA cup sample competition multiple times and check how plausible the outcomes are.

Do you have a road map for your project?

Well, initially, we had a simple 'B' box label for defending, while we were being more specific for the opposition (attacking) box. While this would be a convenient approximation, it still creates a loss regarding the wings outside the boxes (as 'Bw' is used for both attack and defence). Also, we will eventually need to be specific, especially with the 'pitch control' approach. So, it is a good idea to bring back the 'AB' and 'DB' prefixes, for 'attacking' and 'defensive' boxes (opposition and ours), respectively.

In the very first implementation, we are using the time of the next state in sequence for calculating the match duration. While this is practical and it evens out in total, it would be more correct to use the current state's time, because the duration of an action to complete is dependent not only on the action itself, but also on its outcome. We need to treat the whole state - action - outcome - state sequence as a unified chain, which will encapsulate all parameters of the transition between states, rather than split the initial state from its outcome, taking into account only the duration of the latter.

Examples:

Let the initial state be a corner kick. How long the corner kick will take will depend on its action (how it will be taken; not covered in this initial version) and its outcome. Currently, this duration is already predetermined by the previous state in sequence, because it would be convenient along with the outcome to pick also its duration, which however now is split from how the actual initial outcome's state plays out:

Corner Kick -> Corner Kick: 48 sec

if the corner kick results in a corner kick again, the duration added up will be the next corner kick's, even if the transition from one corner kick to the other would sensibly take much shorter time (and its assumed time would again be picked randomly from the previous state's transition).

Let's say we have the transition as specified in the match data:

Possession -> Corner Kick: 12 sec -> Possession

The corner kick taking 12 seconds will lead to a new possession, and it will be added as the initial's transition duration. However, as we don't want to overfit the simulation we will pick another outcome, which, with the current implementation, it will 'borrow' the duration from the next state, while the actual durations will be hidden from the implementation (the 12 seconds will be added as if the corner kick's outcome would be a possession, according to the data, but the simulation changes the outcome, without taking into account the change in duration, as the latter was predetermined when the first transition was selected from the previous state).

While reshuffling the outcomes is the main idea of this simulation, it would be more correct to pair the durations with the initial states rather than their outcomes in duration calculations while determining the outcomes.

Manual testing of match engine output and recording of bugs found. They will normally be resolved one by one, before proceeding to more testing.

I am not happy with the MPN processing code as it is. It is already growing into a maintenance nightmare, where the logic is about reading my own mind and putting the right values in the "right" places, which seem arbitrary and unintuitive at first glance.

A first step towards its improvement is to do some housekeeping, like common best practices, but I think a more drastic approach is required in the less short term (something along the lines of a partial rewrite, while the codebase is still relatively small). One idea would be to separate the construction of the 'flow chain' of events from their actual processing, so that 'dynamic' interventions are integrated more naturally with the data, and the processing and presentation logic are not mixed with 'decision making' logic and (chance) outcome handling.

But still cutting my teeth at this point is welcome, in order to identify as many of the potential issues to be addressed as possible.

UPDATE

It very difficult to debug and reproduce bugs with enough confidence. I need to rewrite the code, without altering something in its logic conceptually, but do the implementation changes mentioned above.

Since penalties are 80% goals, we also need to intervene in their evaluations, as we do for goals, rather than rely on the very limited and consequently biased data.

Hello, first of all, congratulations for this very interesting project (very rare in this field...).
I started watching the code but I'm a little bit lost with all the acronyms (e.g. mv, ttl, mpn. pnw, etc.). Is there a sort of docs to look at?
Thanks in advance.

Currently the pass probability is dependent on a baseline probability (allowing for mistakes), and the distance (vertical and horizontal). We are not concerned at this stage with how tight the marking is; we take it to be the same on average for the whole match duration and pitch. If, according to tactics, there is a marker, then we calculate the pass probability, otherwise we assume the pass has 100% success. We also would like to allow for 'half marking', when a player is loosely marked according to tactics (let's say the winger in a 4-4-2 is marked by a midfielder of a 4-3-3 defending team). In this case, we would like to factor how tightly a player could be marked, not according to the specific match instance, but according to the tactical layout, by attenuating the distance factors.

When intervening on goal attempt outcomes, and possession changes, the attacking team seems to erroneously retain possession.

Take into account time from goal scoring to kick-off.

So, far injury time is not implemented, and we assume that there is a fixed duration for each match. This would be generally fine, in terms of the simulation itself, except the case where penalties are awarded in the end of the match (still not too important, because it is a simulation after all, but also more striking to the eye to pass by). In any case, we need to see how time is allocated for each phase, as there is a lot of implicit 'dead time' included in phase periods, and this also is something to be taken into account in parallel with the specifics of injury time.

Identify and map pass types to their probability of success

Goals and chances are important events and much easier to sample, from a plethora of web sites. We emded these data separately to be used in the flow generated by the raw data.

More on that when it is ready :)

Trivial but good to be reminded.

Get rid of those testing "System.out"s