Nice work!

[KeithBrio]

Do you have a road map for your project?

[atas76]

Hi!

Thanks. You are the first to contact me in the newer incarnation of this project. I don't have a project roadmap, as such. What would you like to know?

[KeithBrio]

I was just looking to see what sort of approaches were out there for this sort of thing. Although not be my preferred language (C#), it is relatively the same and your project looked interesting as you have been updating it fairly regularly.

It does look like the data gathering might be labour intensive. Have you thought about borrowing player data from something like a popular football management game?

Also, looking at your code I can see you've defined Coordinates.Java in your fgn > parser and openengine > engine. Should think about maybe making a shared .dll? To keep them in sync rather than what looks like the same code in different places? Also it might be better to use the full names as it is bad practice to use short hand for names.

[atas76]

My goal for the time being is to reach the level of the old project: https://github.com/atas76/openfootie, in terms of features. This is the so far 'complete' project, but quite clunky in terms of how it was implemented (although it is based on the same idea). For example, the data is in XML and the domain language had a lot room of improvement in terms of 'syntax' and semantics.

I haven't seen many similar approaches myself, that are open source and implemented as standalone match engines. My objective is to make it a 'reference implementation' of a text-based match engine, getting the basic structure right, and then grow it with the aim of being more and more accurate.

Yes, there are not many differences between C# and Java and everything or almost everything should be clear. Maybe, you cold also port it easily, if you are interested in that :-) I think someone mentioned to me that he ported the old project for his own use in C#, but that was a few years back. It's a hobby project and I don't have tons of time, but at least I am trying to keep up with some consistency, so I will keep pushing new updates regularly.

About the data gathering, it is quite time-consuming indeed, but as long as I am trying to keep things experimental, it's not my main concern at the moment. Data gathering (from various available sources) has been another side project of mine, but is is a matter of scaling. At this time, I am interested more in the quality and scope of data, and how these can fit with the logic and produce accurate results, rather with how to scale their gathering. Working also on that, but planning to utilise it later. (And getting more insights from the manual process; accumulation of data is a different problem altogether that I think I should tackle after I will feel pretty sure of how exactly I am going to utilise the data).

About the duplication of Coordinates, I see what you mean now :-D. First of all, thanks for your feedback on the code. There is a lot of refactoring planned; as soon as I am going to get the parser working, and I will be dealing with such issues (and sometimes in parallel as seen fit). In the meantime, every comment or issue spotted is welcome and helpful, but a lot of stuff will change anyway (it's an ongoing project and there are no 'final' decisions).

To go back to the issue of the Coordinates duplication: the first running of the project uses a hardcoded model (the openengine > engine hierarchy), and this is the running version now. Of course, after I ran it at the first time, I realised that hardcoding the model (instead of using XML as in the first project) would not scale well and it would not be the most maintenable representation. In addition, what if I wanted to represent a football match in varying degrees of detail (saving the 'theory' behind this for another time). So it came that creating a domain notational representation language was inevitable, and this is what I am currently working on at the moment (similarly to the original project, in a way). After that, the 'hardcoded' version will be replaced. So, think it for the time being as two completely separate projects that will be merged into one.

I am following a pure TDD approach which works wonders for not being afraid to experiment: each line in the FGN files now serves as a separate test case, and the parser is refactored heavily according to the results (a utility, if you have noticed, runs each line of the FGN in batch mode and new test cases for each new feature or change introduced are implemented). Regarding the shorthands, this falls under the (deferred) refactoring plan, I was writing above. Some shorthands are a conscious choice, but yes you are right that some of them are too cryptic to be useful, eventually. I will try to think of a way to balance this out in a consistent way (naming is hard!). If you have any questions or other comments, ping me in the meantime. Maybe I can make some fast and specific changes regarding the naming.

Another related thing is that now I am trying to decide between having a separate ontology for domain concepts or whether enums would be enough. Enums are certainly adequate at this stage, but maybe it would be good practice to start using some kind of schema for the language (like defining the actions, coordinates, possible states, etc.). Eventually, this should be done in the same way that I started the language to replace the harcoded model, but maybe it is too soon for now. I think I will get things running first and then starting implementing that (no need to do this prematurely, especially with changing and breaking things on the way). What do you think?

That was a long post! I hope I gave you enough information without boring you too much :-D

[tychobrailleur]

I'll join in the praise, as a lurker on the project — great stuff! and I am appreciative of you taking the time writing the previous comment about your thoughts and approach. ;-)

One silly question: what do the coordinates stand for? GK's pretty obvious — but can't figure out the others:

GK, Dg, Dp, D, D_T, D_SP, A_T, C, Aw, A, Ap, ApFTA

[atas76]

Hi! Glad to see myself more responses from this site too (in comparison to the previous incarnation of this project hosted at a different site years ago).

Now, a bit of overview of the current status of the project: the idea is pretty simple; the simulation runs based on sample data from football matches, generating new ones, in a way that makes sense for a football match (eg. rules, realism).

The way it currently runs is restricted on what sample data are hardcoded (in the old engine these were represented in an XML file). This was only a PoC temporary solution as there are some quite obvious drawbacks with this. What triggered me to go towards a more generic solution faster was that varying levels of details and languages can be used to represent that sample data (someone for example might like more detailed coordinates, to redefine the ones above, a different set of actions, or define the possible outcomes differently, etc). So, if a football notation with a specific syntax is specified, those placeholders can be filled with whatever level of detail or ontology the designer would wish, and new match engines could be generated.

One simple example of a syntax is:

coordinate -> action => outcome

If the above syntax is respected (and possibly adheres to a defined ontology), then any user of the engine could write their own football engine according to their liking (there should be some common ground and constraints on that, but the engine would be pretty agnostic to the specific meaning of coordinates or actions; it would only care about the rules of the game, the syntax and checking that a coordinate, for example, is really a coordinate as defined in the ontology)

So, for the time being my focus is exactly on writing a parser for this language (let's call it FGN - Football Game Notation). It started as a pseudo-parser, but thanks to TDD I am finding and adding new test cases, which evolve the project towards being an actual parser almost painlessly. I have created these two FGN "sample" files, and working on these (one of them is done already) for identifying or tackling new cases (and sometimes the language itself changes in the process; the tradeoff is much better if I just simplify the language itself).

As I mentioned in my previous post, the next step is to support an ontology of domain concepts (like allowed coordinates, actions, outcomes, etc.). For the time being, as long as the parser is developed, these are harcoded just as enum values, as I am only working on a default unspecified ontology (which is different than the currently hardcoded one), and the goal at this stage is to load these two sets of data in the main runner and generate football matches in those two different ways (and n ways in the future)

So, after this lenghty introduction, and to reply to your original question, the notations are cryptic indeed. Yes, maybe it would be a good idea to support two different namings : a shorthand one which would be more used and an explanatory one, which could be even a comment. But most importantly, the idea is that in the future it would be up to the designer to define their own coordinate system and own notations. So, for indicative purposes, I'll go through each one now (sorry in advance if they don't make sense or are awful shorthands indeed, and they could mean slightly different things in the current ontology):

GK - Goal kick
Dg - Goalkeeper in penalty area
Dp - Defender in penalty area
D - Defender in "defence area", I define it as the 1/3 of the pitch in front of the penalty area
D_T - Defensive area throw-in
D_SP - Defensive area set piece
A_T - Attcaking throw-in
C - Corner
Aw - Attacking wings (in the current ontology it is the area in the wings in the 30% attacking area, diagonal to the penalty box; for besides penalty box in current ontology it is Awp)
A - Attacking area, in front of penalty box
Ap - Penalty area
ApFTA - Penalty area "first touch" attempt

As you can see, these are just not coordinates, but they also include context, regarding certain in-game constraints for the player ("first touch" attempts are treated differently) or rules of the game. This is a current issue I have with mixing context with the coordinate system, regarding language representation. For example, coordinate "dominates" the context if it is "input state" (as in "input state" -> "action" => "output state"/"outcome"), as by default the status is "normal free play" (pressure, distance from defenders, marking, etc. are other factors for the future of course), while we may be more interested in the actual context of the outcome regarding applying specific rules and looking for specific context regarding the next input state.

It's always good to write on my thoughts from time to time, so thank you for the opportunity to clarify things even for myself and identifying areas for improvement. There are things that should be tackled for sure from a quality perspective, but in the meantime I am trying to drive it forward, making as much sense possible. I will be glad to answer any questions and for any feedback, in the meantime.

[rcboned]

Hi! Very interesting project! I started one engine last summer in Godot, but I don't think my approach was as thorough as yours (mine is first attempt 😄). Given that I'm a PHP developer, how would I run your code? Thanks!

[atas76]

Hi. Yes, there are quite a few approaches and possibilities in this domain, and this is my 2nd attempt with this particular idea. Now, about running the project, my recommendation as the quickest and most intuitive way is to use an IDE like IntelliJ IDEA (https://www.jetbrains.com/idea/), which has a community edition, and also install the Java JDK (https://www.oracle.com/java/technologies/javase-jdk8-downloads.html), for building the project. If you will have setup everything successfully, the dependencies (junit for unit tests and csv parsing library) will be downloaded almost automatically, and it will be straightforward to run the project from the IDE. Since it is a work in progress, there are many "entry points" and things to experiment with, so maybe you will need a bit more researching and poking around to make it run in a meaningful way.

In general, I can think of 3 different ways that this project can be packaged and/or run (as a desktop Java application)

1. Through an IDE, as described above.
2. Build and run manually through command-line. I could write a small guide on this, but writing such guides is not my greatest strength, and I don't see much benefit to it (unless you really want to be IDE agnostic).
3. Me preparing a "binary" JAR file, which you can run with the Java runtime, along with providing a basic user guide (since you will have to run it as "end user").

With any of the above ways, you will need at least the Java runtime environment (JRE) to be installed. And still it needs to be defined exactly what and how it is run (so either a small "user guide" or some understanding of the functionality).

I will provide instructions for all of the above at some point (or a combination of them), to cater also for people who don't have programming background at all and have come across the project (that has also happened).

In the meantime, I would suggest to try and run through an IDE and then ask for more clarifications if needed, so I can also see what needs to be documented as a guide. With an IDE you will also be able to make changes to the project for experimenting and see them live immediately. I won't write a user guide README yet, as it is still work in progress, and it would not make sense to start documenting ever-changing functionality. Check each main() method, and the parameters it accepts, to see how it works and what it does and refer also to the tests (although they are about the utility part of the application of parsing the sample match data). Hope this helps.