openfootmanager / openfootmanager Goto Github PK

Currently the game can only generate databases on-demand for new game sessions. However, I'd like the game to have a default database that it ships with. Something that resembles a real-life soccer database, with slightly modified player names.

This is a huge task to fine tune the teams and players to their accurate representations in real-life, but I'd like to take some time to work on that whenever possible. I guess that more people would appreciate a game with something closer to a real-life database rather than something that is completely random and disconnected from reality. The game would give you the option to use a random database as well, if you wanted to.

In the live game, player stamina is not getting updated. We need to update player Stamina, and factor that into the decision of substituting players.

Club definitions are being automatically generated by web scraping. I can't get team info details from this scraping, so I'm just generating random values for "mu" and "sigma". This can lead to pretty inaccurate details about teams.

We must either manually or randomly tune databases to correspond with actual team performances.

i wonder if you still have passion for this project
im intersted in the live match simulation
i worked on it by myself in my old project , dont you think pygame should be a good choice ?

Create a class to manage the current Game Session. This tracks the current game state and the team that you're currently managing. We can leverage that to create savefiles later on.

Each SimulationEvent must have their own commentaries. For now I'm just using print statements, but I need to use a different approach for Commentaries, so they can be serializable if needed, and displayed in a GUI.

• Implement #42
• New Game UI
• New Game Controller or Module in the "Core"
• Save and Load Game feature to load GameSession

Teams should be able to change formation following some criteria:

• Changing formation does not change the current players playing the game, just relocates them from one position to another. Example: If I change from 3-5-2 to 4-3-3, one player from the midfield becomes a defender, and another one from midfield becomes an attacker.
• The formation change can be influenced by players that are sent off, or players that were removed from the field. AI substitutions prioritize formation change after a sent off, focusing on defensive status. Depends on #48
• Changing formations should reflect the player's overall on the position.
• AI can change formations.
• User must have an UI to change the formations.

Hello,
First, I'm happy to see this new project and hope it will be soon available.

How will you store all the datas of this game (I mean, player's datas, club's datas,...) ? Will you use a database system like Postgresql ?
And will you use maps on this game, for example to locates clubs or stadiums ?

Thanks,

I'm considering using SQLite instead of JSON for in-game database. I'm still deciding over database schema, whether we need to divide data into different .db files, or just use one database with many tables for everything. This is important to create a savefile later on. My ideas for savefiles will go in another issue, but I think if we implement an actual database, we can improve performance to load teams and players.

Another thing I'm considering is to use SQLAlchemy instead of pure SQL. This project uses a lot of dataclasses, so it isn't that bad to convert to SQLAlchemy models.

• Implement #72
• Main Dashboard UI
• Main Dashboard Controller
• Display Club information
• Display Stadium information
• Display current GameSession information
• Display squad and current default formation
• Play live games
• See next opponents
• See championships

First thing I need to focus on: get match simulation right.

I've implemented a first attempt at a match sim using what I've learned from eSports Manager, but now I think for soccer I should implement a different approach.

I'm investigating new ways to implement a match sim.

Players are not currently awarded assists. We must implement assistances following the criteria:

• Assistances are only awarded after goals scored. The game looks if the last event before the goal was a Pass Success or a Cross Success, and awards the passing player an assist.
• Opponent players should not receive assists when the other team scores. (This might be covered by the last condition, but we must check)

As a remediation for teams taking too long to generate and load, I might just add a Loading screen for any time that the game is doing some task that takes a long time to complete. I was thinking about leveraging the Meter widget from ttkbootstrap to use in this loading screen.

Give the user the ability to simulate an entire game without having to click more than once in the Start Match button.

To create a prototype, we must set up a debug mode to test and debug the games components.

The debug mode should be composed of:

• Home page for the debug components
• Match simulation debug mode: pick random teams from the database and let them play a match automatically, without any user intervention to the game. UI should show the match description, current state of player's stamina, goals scored and any relevant match events.
• Team formation debug mode: allow to set up a team formation and validate them.
• Championship debug mode: allow to play an entire championship automatically to test background match simulation and test team's strengths.
• Stats explorer: allow to test and explore the team statistics and player statistics.
• Player profile debug: load player data and present it in a nice UI so we can view the game's players.
• Team explorer: explore teams and see their squads.

These basic functions should be enough to test the game's main components. As we add new components to the prototype, we should add new pages to the debug mode.

There's a bug while updating player data in the tableview. For some reason Tkinter throws an error after the match is done. My suspicion is that there's something to do with the Thread, or with Garbage Collection kicking in before the table is updated. It might not be the case, since we are not deleting the live_game data even after the thread is done.

Another explanation might rely on a bug on the tableview implementation on ttkbootstrap.

This is the error log:

Exception in thread Thread-5 (start_simulation):
Traceback (most recent call last):
  File "/usr/lib64/python3.12/threading.py", line 1052, in _bootstrap_inner
    self.run()
  File "/usr/lib64/python3.12/threading.py", line 989, in run
    self._target(*self._args, **self._kwargs)
  File "/home/sturdyrobot/dev/openfootmanager/ofm/ui/controllers/debug_match_controller.py", line 73, in start_simulation
    self.update_game_data()
  File "/home/sturdyrobot/dev/openfootmanager/ofm/ui/controllers/debug_match_controller.py", line 96, in update_game_data
    self.update_player_table()
  File "/home/sturdyrobot/dev/openfootmanager/ofm/ui/controllers/debug_match_controller.py", line 189, in update_player_table
    self.page.update_tables(home_team, away_team, home_reserves, away_reserves)
  File "/home/sturdyrobot/dev/openfootmanager/ofm/ui/pages/debug_match/__init__.py", line 120, in update_tables
    self.player_details_tab.update_tables(home_team, away_team)
  File "/home/sturdyrobot/dev/openfootmanager/ofm/ui/pages/debug_match/player_details_tab.py", line 106, in update_tables
    self.home_team_table.load_table_data()
  File "/home/sturdyrobot/.local/share/virtualenvs/openfootmanager-ITedqgPF/lib/python3.12/site-packages/ttkbootstrap/tableview.py", line 1041, in load_table_data
    self.unload_table_data()
  File "/home/sturdyrobot/.local/share/virtualenvs/openfootmanager-ITedqgPF/lib/python3.12/site-packages/ttkbootstrap/tableview.py", line 1023, in unload_table_data
    row.hide()
  File "/home/sturdyrobot/.local/share/virtualenvs/openfootmanager-ITedqgPF/lib/python3.12/site-packages/ttkbootstrap/tableview.py", line 332, in hide
    self.view.detach(self.iid)
  File "/usr/lib64/python3.12/tkinter/ttk.py", line 1230, in detach
    self.tk.call(self._w, "detach", items)
_tkinter.TclError: Item I0CF not found

It's pretty inconsistent, and might happen once or twice, or even not at all.

SimulationEvents are currently an untested mess. I need to write tests for them, but they're pretty random, so I have to refactor them to get them to a testable state. My idea is to extract all the randomness into functions, and monkeypatch them to always return the same results in pytest. That way we only need to test what the events return, and the logic behind them. After that we can test the integration between SimulationEvents and the SimulationEngine itself.

Introduction

OpenFoot Manager is exactly what the name implies: a Football (Soccer) Manager game. Based on famous franchises, such as Football Manager and the now deceased Championship Manager. This game was born after looking at the available alternatives in the open source market, and after the Bygfoot game was abandoned.

The idea is to bring the gameplay experience you would find in these legendary manager games, without any of the limitations that the other alternatives present to the player:

• You don't need to be connected to the internet to play this game
• You don't need to create an account on a website
• You don't need to wait hours to get to play a match
• You don't need to set up a hundred different things for each player of your roster to get them to play better each game
• You don't need to buy packs of cards to have the chance of getting a good player
• No lootboxes, no pay-to-win
• No license fees
• No restrictions to what you can do with this game whatsoever
• There's no over-complicated game mechanic: most things should be self-explanatory and pretty much straightforward

Gameplay Overview

How will it be played?

Following the standard of manager games, the game mostly relies on the mouse to be played, with screens and buttons to be clicked on, and text output with information about what's happening in the game.

Game Session

As soon as you start the game, you can choose to start a New Game, Load a previous game, configure game settings or exit the application. When you start a new game, you're given the choice to create your manager and then to choose the team that you want to play. You can also create a new team and drop it in a division that you want to play in. There are no restrictions of team choice. You can only choose one team per game session. You are not allowed to edit the players once you enter the new game session as well.

The game will be able to generate an entirely new database of teams and players from scratch, or even load an existing database, if the player wants to.

Once you start your game session with the team of choice, you should get options see your squad, see news of other teams and what is going on in the world of soccer, and see your calendar of games. There should be options to configure your team's default formation, your playing strategy, and you should be able to interact with the database by searching for players or teams, as well as try to negotiate with players and bring them to your team.

The game should also present you with the option to view and manage your team's finances, and manage your team's staff. The user can hire better staff members to get better input of other player's performances and increase the players' recovery time.

Playing a Match

When playing a Match, you should define the team's formation, and it's up to you to choose your team's strategies.

The Match will pop up with info about the current match status and score. That's when Match Live Commentary comes up: every now and then the teams will perform an action, and their actions will show up on the user's screen, just as if there is someone casting this game.

At the end of the match, all data will be updated with the scores, performance ratings, which will affect player's performances and form later on. This means that if you're team is on a winning streak, they're going to get hyped up for next games, and this is going to increase the chances of winning other matches. Going on a losing streak, on the other hand, will demotivate your players and will increase your chances of getting fired.

Hiring players

Hiring new players depends on your financial situation. You can either approach other teams to hire them, or find new talents in the Youth Academy. These prospects will have potential skills that can be explored, and if you practice a lot with them, they might reach their peak.

Sponsors

Sponsors provide ways to get financial and performance boosts. Each season you will get approached by sponsors to sign contracts, depending on the relevance of your team. If your team is very strong, bigger sponsors will offer very significant contracts. Your sponsorship depends on your team's performance, and the financial boost might come with specific requests ("score 5 goals in the next match", "win against your rival", "win 3 games in a row", or so on and so forth). Every so often the sponsor will provide items that might boost players' performances temporarily or permanently. It's up to you to choose what's best for your team at certain points.

Practice

Your team has to practice regularly to improve player's forms and boost their morale. You can relegate practice matches to an auto-manager, that will do an okay job at it, but people that want to get the full experience can take control of practice match and do their best to improve the roster the best they can.

Major championships

Winning a league might qualify your team for major championships, such as Champions League/Libertadores or other International Competitions. Winning these championships will provide a major financial boost and will make your name desirable for other teams.

These are right now the main aspects planned for the 1.0.0 release of the game. Further details are going to be found on a future Game Design Document.

Development

The game is developed using Python 3 (currently 3.8.3), using a Pipenv. You will find all the project's requirements in the Pipfile. You may find specifics in the CONTRIBUTING file as soon as it's ready for Contributing. You will also find every information needed to get this project running on your machine, and the code style used in this project. Please, also follow the Code Of Conduct described there, so any contributor that does not follow our Code of Conduct will be dismissed.

License

The license is GPLv3. Defined on the License document and on Readme as well.

Teams take too long to generate and load when you want to debug in the match debug. I want to come up with a way to optimize this, which might be related to #35

As a general remediation to this issue #38 might provide a good immediate feedback to users for tasks that will take longer anyways.

Trying to add widgets and new tabs to the DebugMatch GUI is starting to get bloated. The code is too long, and we can refactor it into smaller pieces for each tab and function.

It needs a refactor. This is what I want to do:

• Move all the tabs contents to their own classes deriving from the ttk.Frame class.
• Reuse existing code when possible and remove potential code duplications
• Make it easier to add new tabs and widgets to the existing code

I've introduced a way to load teams in the Debug Match page here 82abf40. It's perhaps not the best way to do this, but it might be done. However, I suspect that the database is too big, and it might not load things correctly, since it takes too long and uses too much CPU to do so.

I need to find a way to load teams more efficiently, and to make it so it doesn't crash or uses too much CPU.

Stadiums can be separate entities from Clubs. We can organize a separate database only for Stadiums, so that games can be played on neutral grounds as well.

In this point in time, the game uses a database with names of existing teams.

To avoid issues with copyright infringement and potential lawsuits from soccer authorities, we should not distribute the game with real team names and data.

The Team generation should generate a random database of teams, based on a couple of parameters in definition files. Names of the teams should be randomized according to their locations.

Initial implementation is being worked on the rework branch.

I'm investigating using Pywebview as an alternative way to program the frontend. Pywebview is basically an "Electron" for Python projects.

We can create a Flask server to expose the relevant API to the frontend, and program the frontend in JS frameworks. Now, I'm a terrible frontend developer myself, and I don't really like working with JS, but I know that there are a lot of competent JS developers that can improve that, so that's a good way to get people to contribute to the project.

Personally, I'd love if we could minimize the amount of JS (I'm not too fond of that. The few times I've used it I had so many headaches with the dependency hell created by Node.js, and with the bloated packages generated by it), and I'd love to go for a more HTML-centric approach, using at least HTMX and Tailwindcss. However, I know that React is pretty popular and that a lot of people would prefer working with that, so using React here is really a no-brainer.

I'll do my best to implement the basics with ttkbootstrap to create the prototype, but as soon as I'm done with it, I'll try Pywebview as an alternative UI.

• #48
• #72
• #73
• Compile a Debug release with PyInstaller
• Write a GitHub action script to publish current game releases

Hi,

Thanks for the project! I've just started to work on Python recently and I want to work on an open source project to improve my skills. Your project really interests me!
I want to know if you're looking for contributors and if yes, have you planned to add in the readme how to run the project?

To generate teams and players for these teams, I had a couple of ideas that I expressed in #13 .

I'm settling in an option to generate the teams definitions according to a definition file that includes the team's name, region, and expected skill lvl.

We have a lot of football regions, teams, leagues and championships, so I'm going to rely on an open source football database called football.db which is part of sport.db. But we might run into copyright issues if we include teams/championships real names.

So here are some things that I'd like to do for these definitions:

• Define the format and standards for the definitions file. How extensible will it be? Do we need more than one file for that? Bygfoot distributes several XML files for definitions that you can add separately, but I believe that we can just deliver a single JSON file with all definitions.
• Distribute a default definitions file that has generic team/championship names (probably just randomly scramble the characters of teams, or manualy edit them)
• Create a script that downloads these definitions and converts to a format that OFM understands and can work with, so we don't officially distribute these files with official names. This script can be delivered with the official release of OFM, or as a separate software that interacts with OFM.

The UI is only going to display commentary according to user-defined settings. If the user wants to see all the events, all commentaries will be enabled. If they only want to see important events, only goals and free kicks are going to appear.

The penalty shootouts feature is a special case in match simulation. Probably a sequence of Penalty events, but we need to make a few adjustments:

• Let the user decide the order of penalty shootouts
  • Implement a UI for that
  • The game can make suggestions or automatically sort the list of players based on penalty skill
• Implement a special UI for penalty shootout results
• Check the penalty events and tune them for penalty shootout situations
• Implement penalty shootout rules

PlayerAttributes are getting more specific. I recently made a change to potential skill to be only an overall number, and following this change, I want to make PlayerAttributes way more specific to make the simulation more interesting.

PlayerAttributes will have more specific attributes, and the overall calculation will get a little bit more complicated with this change. I will also need to tune the Generator function to generate these properly, so this is a very big change to come.

They will be broken down into a few attributes:

• GK: Goalkeeper-specific attributes
• Physical
• Defensive
• Intelligence
• Offensive

GK

• Reflexes
• Positioning

Physical

• Strength
• Aggression
• Endurance

Defending

• Tackling
• Interception
• Positioning

Intelligence

• Vision
• Passing
• Crossing
• Ball control
• Ball skills
• Dribbling
• Team work

Offensive

• Shot power
• Shot accuracy
• Free kick
• Penalty
• Positioning

This means that to calculate a player's overall for a position, these attributes are worth more.

• FW: (Gk * 0 + Physical + Defending + Intelligence * 2 + Offensive * 3) / 7

• MF: (Gk * 0 + Physical + Defending + Intelligence * 3 + Offensive * 2) / 7

• DF: (Gk * 0 + Physical * 2 + Defending * 3 + Intelligence + Offensive * 3) / 7

• GK: (GK * 3 + Physical * 2 + Defending + Intelligence * 0 + Offensive * 0)/6

• Implement new PlayerAttributes with these subclasses

• Implement new PlayerAttributesGenerator to account for these

• Change get_best_position

• Change how overall is calculated based on the attributes

• Change the tests to account for the new PlayerAttributes

I have tried to add some tests using the "hypothesis" library. Hypothesis is a property-based testing tool, to help us generate data for testing.

For projects with a lot of data that is randomly generated, like this one, property-based testing is great for testing the project against more data than we already have.

Before the Match Simulation, each team has to set up the players on the field and the players on the bench. Right now I have the Formation class which is pretty much just a dummy class.

However, setting up a team formation is a pretty important part in football, so we should come up with a method to set them up in the game. Following work items are required:

• Formation class should validate and represent the team's formation. Invalid formations will not be accepted:
  • Teams without 1 goalkeeper playing or without at least 1 goalkeeper at the bench at the beginning of the game.
  • Teams without the minimum amount of players to start the match.
• Once the game starts, the formation should also keep track of players that are substituted in the game. Players that are injured, are substituted, or that were sent off should not be able to come back to the game.
• Formation can be changed during a game.
• There should be a UI page to select players before and during a game.

As I'm implementing the events I realize that TeamStrategy matters a lot to how the teams will play the game. They influence the transition matrix between events, so I decided to kickstart a TeamStrategy implementation.

Teams will have the following strategies:

• Normal: very reasonable transition matrix for passing and shooting
• Keep possession: transition matrix focused on passing and shooting only when very near the box
• Counter-attack: transition matrix focused on long passes and crossing
• Defend: transition matrix focused on keeping the ball on the defensive side
• All attack: transition matrix focused on long passes and shooting whenever possible

Hopefully we can see a big variety of play styles from these alone. I'll also implement a way for the user to switch the strategies mid-game, and I will add a combobox to the Debug Match so you can play with the different styles for each team.

Breakdown:

• Implement team strategies enum
• Implement the TeamStrategyFactory
• Implement transition matrices for passing, event transition, crossing and shooting
• Implement the combobox in the Debug Match

With new PRs coming up, it's hard to keep up with new features and code changes. I need to set up a CI/CD environment to get ready for contributions and make it easier for us to review new code.

@sturdy-robot could you please update the requirements.txt with the acutally used packages? I installed the project in a fresh virtual environment. I needed to install pyyaml and ttkbootstrap manually, because they are missing in the requirements. There is also PySide6 in the requirements, which isn't used at the moment if I'm correct. This is a quite large package. Maybe there are more unused packages, that I didn't see.
Could you please remove the unused packages and add pyyaml and ttkbootstrap?

I want to work with a very simple GUI for prototyping the game's features. As much as I want this game to have a core independent from the GUI, and anyone could use the core and develop their own GUI on top, I just think working with a GUI for prototyping and getting ideas out there is a better method.

Initially I wanted to work with Qt, but I'm not too fond of Qt lately. Perhaps in the future I can look forward to working with it.

With eSM, I used PySimpleGUI. It's a simple enough GUI system that can get things done quickly. However, I had to develop a complex system to deal with layouts and controllers, which I don't think can be reusable. Although PySimpleGUI is awesome for prototyping, I was exploring other ideas.

Recently I found Ttkbootstrap, a wrapper around Tkinter, Ttk and PIL, which makes working with Tkinter a little bit less painful, and with gorgeous Bootstrap-inspired Ttk themes. One of my main issues with PySimpleGUI was updating the layout theme in real-time, which doesn't seem to be a problem in Ttkbootstrap.

I'm coming up with simple designs for the prototype.

My idea with this is to deliver a minimum viable product, where the user can interact with the game without using the terminal. It should be simple enough to get started, after so long just staying in the realm of testing with pytest only.

Later on, as the game progresses and develops even further, we can explore new GUI systems, and develop a GUI-independent API to make the core much more reusable and expandable.

I want to create a SQL database out of the game's data. JSON files are fine and can be an option to store and modify data, but I believe that, in the long-term, SQL databases are more suitable options for the game. The Core of OFM could be, at any point in time, used for implementing a web-based application, so I believe using proper databases is the way to go here. Even if my initial goal is to implement only a desktop app, I can see someone wanting to use this for a web-based app, so we can make this easier for anyone to use the game's data.

For that, I think SQLAlchemy is a suitable option to accomplish that goal. It's one of the most robust ORMs in Python, and can be used with basically any database system. My initial goal is to only implement a SQLite database, as described in #35 , but in the long-term, I could use it for any database system.

Adapting the code to conform with SQLAlchemy will take a while, but I think it'll be worth it.

Implement a Substitution system.

• Substitution for the user
• AI system for opponent's substitution
• Checks for GK presence in the game. If a goalie is sent out, the game cannot progress unless another player is relocated to the GK position.
• Switching players' positions when they're already playing on the field does not change their "substituted" status.
• Work on UI interaction to make it easier to substitute and relocate players
• Player can open substitution screen anytime during the match, which pauses the live game.
• Check amount of substitutions left. You can't substitute players if there are no substitutions left.
• Check for injured players. Injuries that require substitution will instantly prompt the substitution screen if there are substitutions left to make. Otherwise, the game tells you that you'll be playing with one less player.
• UI for substitution.
• Let the player choose the formation in the UI.
• The user can swap player positions.
• Let the user choose if they want the game to make automatic substitutions.
• Implement a substitution AI.
• If a player is sent-off, the game automatically prompts the user to make a substitution, if automatic substitution is turned off. If the player has no substitutions left, the game will only prompt the substitution screen if the player is a Goalkeeper, so the user can choose which player will take the place of the GK.
• Sent-off players cannot be subbed.
• Players that were already subbed cannot come back to the game.
• Players that are greatly injured will prompt the user to make a substitution, if automatic substitution is turned off. If the player has no more substitutions left, the game will tell you that one player is unavailable.
• If the team has 5 less players on the field, sent-off or injured without substitution, the game is terminated and a 3-0 score is awarded to the opponent team.

Introduce a delay to each event happening in the game, to give the impression of a real-time description. Delays will be user-defined.

Just a small enhancement to add to the Offensive attributes:

• weakfoot: Considers how skilled the player is with their weak foot.
• header: How skiiled the player is with the head.
• header_accuracy: How accurate is the player's shot with the head.

These attributes will be used in the ShotEvent to calibrate the player's final probabilities of scoring.

In this point in time, the game uses a database with names of existing players.

To avoid issues with copyright infringement and potential lawsuits from soccer authorities, we should not distribute the game with real player names and data.

The Player generation should generate a random database of players, based on a couple of parameters in definition files. Names of the players should be randomized according to their nationality, and their skill level should also correspond to their nationality.

Initial implementation is being worked on the rework branch.

This is the roadmap for Openfoot Manager. This roadmap represents the current plans for each version of OFM, and which features should be prioritized in these versions. The roadmap is subject to change without further notice as development goes on.

In this high-level roadmap, discussions about the underlying architecture is irrelevant. The game's architecture is entirely subject to change, and should be discussed with the developers and collaborators of the project.

The strategy of versioning follows Semantic Versioning (SemVer).

0.1.x

First release of the game, where the foundations are laid out. In this release, we work on the essential features for the game. A lot of features that are not considered a priority will be left out of this release.

This can be considered an alpha release, so this is the first step into making a stable game. This release should not represent the final product.

This release must include:

• Match Simulation
  • Text-based Match Simulation
  • Goals, fouls, penalty shootouts, free kicks, yellow card, send-off, substitutions and the computer-controlled opponent should also be able to make decisions (substitutions, change formation, etc)
• Create a new game session
  • Create your manager and provide manager details
  • Select the team that you want to control
  • Select the players that you want to play the game
  • Change formations
  • See dashboard of next games and practice
  • Player stamina and form
• Save and load game
• Database of players, with random player generation or even using an existing player database
• Database of teams and possibly of regions
• Only one championship (the one that the player is playing)
  • Match scheduling initial implementation
• Simple GUI

The following items are optional for this release, which might be implemented if we can fit into the initial foundations:

• Finances
  • Player transfers
  • Player contracts (wages, bonuses, etc)
• Player progression
• Select region to play the championship
• Start supporting translations

All the other potential features are not considered priority at this point. The initial release will give us the confidence to implement more features.

0.2.x

If any of the optional items of the previous release were not implemented, this release should now include them.

This release is where things are substantially improved. The game should be more robust at this point, and whe should be able to identify the issues that need our attention. Above that, these items must be implemented:

• Championship types (Cups, Leagues)
  • National and international championships should be considered
• Manager approval
  • This is like a termometer that tells you how much approval you have of the club's board of directors. If your termometer gets too low, you can be fired at any time.
  • Firing may result in the end of the game, or new job opportunities might pop up in your screen (low priority to implement this last option)
• Job opportunities
  • The ability to change teams as soon as opportunities appear
  • Maybe give the player the opportunity to manage a national team
• Youth academy
  • Find new young players for your team
• Assistant manager
  • An AI-controlled manager that should provide initial suggestions
  • Start implementation of player scouts (low priority)

In this release, the player must be able to choose the region and team that they want to play. They must be able to transfer players and deal with the club's financial issues. The championships are now expanded, so you can play more than one cup at the same time.

With the manager approval meter, the player now has to please the demands of the club's board of directors, and try not to get fired from the job. And you can now watch your squad improve as you play the game, with the player progression system.

0.3.x

Following this release should come major improvements to the game's core gameplay mechanics. In this release we can focus on the visual aspects of the game:

• Improvements to UI
• Add club logos and player portraits, if they're not already in the game

Not only that, the game should now have a solid foundation to add more enhancements:

• Sponsors
  • Get sponsor contracts to improve the club's financial gains
  • Accomplish sponsor-imposed challenges to receive greater bonuses
• Financial improvements
  • Set up marketing campaigns for the team
  • Sell shirts and club merchandise to improve your financial situation
• News articles
  • You should get a summary of what happened in the world of soccer/football in the latest weeks, with a system that generates "news articles" that should resemble what you find in a newspaper and sports magazines
• Assistant manager AI
  • Improve the assistant manager AI to offer more suggestions
  • The player scout's AI should offer improved player suggestions.
  • You should be able to choose the scout that you want to hire. Better scouts offer better accuracy in predicting a player's potential skill lvl

0.4.x

At this point we should start thinking about implementing a 2D match simulation engine.

0.5.x

No plans defined.

From here on now there are no plans. This roadmap will be updated as soon as the development picks up the pace. If we start focusing on deadlines and dates to finish each version, we will also add these dates to the roadmap.

I think it's important if we can make both games kind of compatible with each other. I want to get Bygfoot's definition files and parse them using Team and PlayerGenerators. Bygfoot's definition files are a good source for player names and skill generation, so it should be very interesting to make it also work in OFM.

However, OFM might also need to generate extra information that is not in Bygfoot's code, so it should generate new data not in the XML files.

Work on a Team Selection screen for players to see how they would go about selecting their team to manage in the game.

Some player names are written in different alphabets, like Japanese, Korean, Arabic. To make it less of a hassle to store in databases and read them in other languages, we might need to convert all of these characters to standard romanic languages.

There are a few options to solving this:

• We change the names.json file and convert all the names to their romanic equivalents.
• We use a realtime converter to convert names on the fly.
• We save player names with their original alphabet and a romanized version of the name, which is used by the UI.