alumarcu / dream-framework Goto Github PK

A base for coding online sports management games, built with soccer in mind; powered with Django and PostgreSQL

License: GNU General Public License v3.0

Python 74.29% HTML 8.34% Shell 3.28% JavaScript 13.22% CSS 0.88%

dream-framework's Introduction

Dream Framework

The project aims to build a framework useful in building sports management games, with team-oriented games in mind, we are initially implementing a match engine for association football (soccer).

Contribute

Please contact me (alumarcu__at__gmail__dot__com) if you like what we've done so far and would like to know how you can contribute.

Installation and Setup

First, rename your settings_dist.py file to settings.py and customize database params
More details coming soon!

dream-framework's People

Contributors

Stargazers

Watchers

dream-framework's Issues

[SIM-07] There should always be actions, this should be a failsafe only

As a rule, a player should always have an action to perform (i.e. Rest), in the absence of one an error will be logged

[ENV-01] remove and remake migrations

Part of

[ACT-05] Kickoff role should be given by the player based on some logic, not defined by a human

[ACT-03] Field player roles should be defined in db rather than constants

[TPL-01] Add locale as attribute to <html> tag

[SER-08] Should be moved to an utility module

[SIM-01] Tactics validation

Dummy unit tests (and add to pre-commit)

Unit tests are not a priority for v0.3 but some should be in place as an example for future tests.
Also, those that exist should work and unit tests should run on pre-commit.

[SER-06] User should be able to decide if the name of the team is same as club's

[SER-01] Initial players in team: database param should be created

A database parameter (engine_param) where we define how many players are initially created for a team

[ACT-09] Randomization limits below are calculated on discipline

Randomness should depend on discipline

[SER-03] Create relevant exceptions for Service and Signup process, or just generic site errors

[FOR-01] Only alphanumeric and a few special chars should be allowed in username

Better admin management interfaces

To allow for better manipulation of complex objects added for testing purposes (e.g. actions & requirements)
Includes:

[ACT-12] Instantiate the action class from the player action with row data

[VIW-01] Remove redundant code used for displaying the page

Check if still an issue

[SIM-05] A player from the opposing team should follow, check ordering

Deals with the ordering of players actions in a tick.

After the ball action was performed, one (or more) players should perform counter-actions, and also players without ball in the team that holds the ball should aim to counter the counter-actions. After all players dealing with a ball action or counter-action have been moved, players that do not deal with the ball should be moved.

Is the above correct? Player initiative and reflexes will certainly play their roles, as will tactics. So how do we fit all these concepts together?

[SER-07] TBD - choice of gender before choice or league or vice versa

Should the user first choose the gender of his team and then be offered with the available leagues OR should the user be first shown the available leagues and decide on gender afterwards.

OR... use two controls that automatically update each other. All leagues are shown when the gender control is set to undefined, and update it dynamically when a gender is defined.

[SIM-02] Research abstract classes (ABC's) in Python and decide whether its the case here

Also valid for other places

[ACT-04] Multiple players can have ball action

[MOD-03] Build a specialized class for stadiums

Also look into definitions of "home" and "away" as roles in a match vs actually hosting the game and getting money and crowd morale for it. Changes should be made to take neutral stadiums into account; and "home"/"away" roles should be renamed to anything else ("team_a" and "team_b", or whatever)