Groundhog learns Python - Road to a Basketball Text Sim

[Groundhog]

I've moved away from templates for players. Now I've set 5 ranges for player abilities, from terrible to great, and set a chance for each position to fall in each range.

Here's an example of the players generated from different talent tiers. Speed/strength are affected by height and weight, but there is a chance that a player is an exceptional athlete, which can increase the strength of the player but right now is not adjusting the weight when triggered, so a 6'10 SF can be a 17 for strength while weighing just 198lbs. 3 point ability is the only rating that is being generated using the new method, and needs to be improved for talent tiers 1 through 4 as too many guards are being generated with lousy 3P ability. Age is also just a number here, eventually it will affect the players ratings positively or negatively, depending on the age.

Chad roster, talent tier = 1, player heights = taller than average:

NAME: Armand Issa POS: PF
AGE: 24 HGT: 6'10 WGT: 214
SPD: 12 STR: 17 3P: 1
NAME: Abakar Nadjibang POS: PF
AGE: 36 HGT: 6'8 WGT: 255
SPD: 6 STR: 11 3P: 1
NAME: Habib Hissein POS: C
AGE: 23 HGT: 7'1 WGT: 239
SPD: 3 STR: 12 3P: 1
NAME: Mbaimamgone Madjiyedjim POS: C
AGE: 32 HGT: 7'0 WGT: 261
SPD: 5 STR: 14 3P: 1
NAME: Dominique Aldongar POS: SF
AGE: 24 HGT: 6'9 WGT: 255
SPD: 5 STR: 11 3P: 3
NAME: Oumar Kabir POS: SG
AGE: 30 HGT: 6'2 WGT: 216
SPD: 10 STR: 3 3P: 2
NAME: Hilaire Banio POS: SG
AGE: 28 HGT: 6'3 WGT: 203
SPD: 10 STR: 6 3P: 12
NAME: Roland Teinkor POS: GF
AGE: 32 HGT: 6'7 WGT: 217
SPD: 8 STR: 7 3P: 2
NAME: Position Kédigui POS: G
AGE: 20 HGT: 6'6 WGT: 214
SPD: 8 STR: 6 3P: 9
NAME: Dominique Banio POS: PG
AGE: 30 HGT: 6'0 WGT: 193
SPD: 12 STR: 3 3P: 10

New Zealand, talent tier = 2, league height = average:

NAME: Jamie Hardie POS: PF
AGE: 22 HGT: 6'8 WGT: 254
SPD: 5 STR: 5 3P: 1
NAME: Glen Toone POS: C
AGE: 32 HGT: 6'11 WGT: 265
SPD: 4 STR: 13 3P: 5
NAME: Tom Morgan POS: PF
AGE: 27 HGT: 6'8 WGT: 255
SPD: 5 STR: 6 3P: 11
NAME: Whetu Hemopo POS: F
AGE: 23 HGT: 6'7 WGT: 233
SPD: 7 STR: 7 3P: 1
NAME: Junior Ellison POS: G
AGE: 22 HGT: 6'2 WGT: 189
SPD: 8 STR: 2 3P: 8
NAME: Liam Moeke POS: SG
AGE: 29 HGT: 6'5 WGT: 221
SPD: 12 STR: 11 3P: 5
NAME: Whetu Bates POS: SG
AGE: 22 HGT: 6'3 WGT: 213
SPD: 14 STR: 6 3P: 1
NAME: Jack Bradley POS: G
AGE: 27 HGT: 6'0 WGT: 195
SPD: 13 STR: 1 3P: 8
NAME: Andre Curtis POS: G
AGE: 35 HGT: 6'1 WGT: 175
SPD: 14 STR: 3 3P: 1
NAME: Tama Cleaver POS: PG
AGE: 28 HGT: 6'1 WGT: 207
SPD: 13 STR: 2 3P: 5

Crotia, talent tier = 3, league height = average:

NAME: Tomislav Grgic POS: PF
AGE: 23 HGT: 6'8 WGT: 258
SPD: 3 STR: 7 3P: 1
NAME: Miljenko Blazevic POS: FC
AGE: 31 HGT: 6'7 WGT: 215
SPD: 11 STR: 6 3P: 6
NAME: Stipe Situm POS: SF
AGE: 33 HGT: 6'6 WGT: 201
SPD: 9 STR: 8 3P: 1
NAME: Hrvoje Marusic POS: SF
AGE: 31 HGT: 6'4 WGT: 193
SPD: 9 STR: 8 3P: 15
NAME: Ninoslav Vucemilovic POS: GF
AGE: 26 HGT: 6'6 WGT: 233
SPD: 12 STR: 5 3P: 1
NAME: Borislav Kresinger POS: G
AGE: 25 HGT: 6'4 WGT: 206
SPD: 10 STR: 5 3P: 11
NAME: Mario Tomecak POS: GF
AGE: 22 HGT: 6'6 WGT: 213
SPD: 9 STR: 8 3P: 5
NAME: Ivan Vidakovic POS: GF
AGE: 22 HGT: 6'5 WGT: 213
SPD: 10 STR: 7 3P: 5
NAME: Boris Parazajder POS: G
AGE: 26 HGT: 6'2 WGT: 215
SPD: 13 STR: 7 3P: 17
NAME: Ante Turina POS: G
AGE: 24 HGT: 6'5 WGT: 228
SPD: 11 STR: 9 3P: 1

France, talent tier = 4, league height = average:

NAME: Guillaume Cairo POS: C
AGE: 29 HGT: 6'11 WGT: 205
SPD: 6 STR: 5 3P: 7
NAME: Julien Camerling POS: PF
AGE: 23 HGT: 6'7 WGT: 245
SPD: 7 STR: 8 3P: 6
NAME: Romuald Masson POS: SF
AGE: 22 HGT: 6'5 WGT: 192
SPD: 7 STR: 3 3P: 1
NAME: Ximun Gomis POS: GF
AGE: 27 HGT: 6'4 WGT: 208
SPD: 18 STR: 12 3P: 5
NAME: Fernando Vauvy POS: SG
AGE: 20 HGT: 6'5 WGT: 224
SPD: 14 STR: 8 3P: 12
NAME: David Hamed POS: SG
AGE: 24 HGT: 5'11 WGT: 203
SPD: 14 STR: 2 3P: 6
NAME: Carl Soubervie POS: SG
AGE: 35 HGT: 6'5 WGT: 230
SPD: 12 STR: 10 3P: 4
NAME: Ludovic Bouraoud POS: GF
AGE: 33 HGT: 6'7 WGT: 207
SPD: 13 STR: 12 3P: 4
NAME: Jacques Obriot POS: PG
AGE: 22 HGT: 5'9 WGT: 184
SPD: 16 STR: 4 3P: 2
NAME: Gerard Laurent POS: PG
AGE: 23 HGT: 6'1 WGT: 180
SPD: 14 STR: 4 3P: 12

And finally USA, tier = 5, height = above average:

NAME: Mike Harvey POS: C
AGE: 27 HGT: 7'0 WGT: 254
SPD: 7 STR: 14 3P: 10
NAME: Tanner Reed POS: C
AGE: 23 HGT: 7'1 WGT: 249
SPD: 4 STR: 11 3P: 1
NAME: Kirk Massimino POS: C
AGE: 22 HGT: 7'1 WGT: 257
SPD: 4 STR: 11 3P: 5
NAME: Christian Williams POS: SF
AGE: 30 HGT: 6'9 WGT: 212
SPD: 9 STR: 10 3P: 15
NAME: Shane Major POS: G
AGE: 37 HGT: 6'4 WGT: 210
SPD: 9 STR: 14 3P: 6
NAME: Jordan Richard POS: G
AGE: 22 HGT: 6'6 WGT: 212
SPD: 14 STR: 8 3P: 5
NAME: Robert Davis POS: G
AGE: 30 HGT: 6'8 WGT: 227
SPD: 7 STR: 7 3P: 10
NAME: Matt Lang POS: SG
AGE: 24 HGT: 6'6 WGT: 231
SPD: 10 STR: 8 3P: 11
NAME: Rasean Rashford POS: G
AGE: 29 HGT: 6'7 WGT: 217
SPD: 7 STR: 6 3P: 5
NAME: Evan Robinson POS: PG
AGE: 20 HGT: 6'3 WGT: 222
SPD: 12 STR: 4 3P: 5

[Groundhog]

I was so sick of using excel that I decided to create my first UI for the sim, the editor screen for player generation:

[SirBlurton]

I'm blown away by how quickly you're progressing on this project - it looks fantastic!

I've been working on a much simpler project for a much longer period of time with much less to show for it!

What did you use to make you UI?

Was also wondering about the names in your samples - do you have a system for generating names based on nationality? I found a names module but it's strictly for US nationals.

[Groundhog]

Thanks!

The UI was made with QT Designer, which is a very easy to use, graphical form/widget builder - it took me maybe 30 minutes to create the form above as far as layout goes. There is a Python plug-in called PyQT that then takes the QT UI file and translates it to a Python script, so all the actual functionality of the buttons/comboboxes etc. can be done in the Python language.

The functionality part of the above form is still a WIP - it forced me to re-do how I was storing the settings for the generation stuff, using Python's pickle function which I didn't bother learning before because I didn't see how it would be useful... until it turned out to be exactly what I needed, as seems to often be the case.

Re: the name files, I have 80 nations done so far, some I put together manually for FBB over the years, but most of the others were done by text-scraping wiki team pages for domestic soccer leagues, as a surprising number of English-language wiki pages have a detailed rosters. There's still a manual step of going back and deleting out foreign players from each league, but it's still quicker than the old "copy+paste+edit" method I used to use.

The current plan is to have 100 different nations available, but that will change when I start to look at World Cup qualifications way, way down the track, making sure I have a balanced amount of teams per the 5 FIBA regions.

[johnnyshaka]

AWESOME READ!

I've often tried to learn Python over the past dozen years or so but always petered out after a month or two for whatever reason. Having a goal to make a game (or coding something you're obviously passionate about) makes so much sense and I wish I had thought of that during my several go arounds at learning it.

I may give this another try sometime soon but first need to find a good idea that I'm passionate about to drive it along. Thanks!

Good luck and keep us posted, GH!

[Groundhog]

Thanks for reading! Yep, it's definitely helped being able to apply what I'm learning to something I've always wanted to do, 1000x.

[Groundhog]

I spent far too long yesterday working on generating player's home towns/states. For international guys it's pretty simple - I have generally between 20-50 cities listed for a nation, ranked by population, and the chance of the top city being picked over the bottom ranked city is x times the chance, where x = total cities. For example, if CityA is #1, and CityB is #30, CityA is 30 times more likely to be picked. This is a simple calculation, and I can quickly pool together all the cities I'd need to populate the generated players.

It gets more complex in the US because we bring states in to play. The first thing I did was take all the data I'd scraped on all Div 1 men's college basketballers to get the frequency of players coming from the different states. Once I have the state, it's time to fetch the city.

Given how easy it is to get an enormous list of US cities with population numbers, I thought I'd be clever and setup completely realistic distribution of cities per state - ie. if 71% of people from North Dakota come from Fargo, same would be true here. This was fairly easy to do but incredibly slow - with a list of around 10,000 cities, it took 19 seconds to return 100 player home towns.

I ended up trimming the cities list considerably, 30 a state where possible, and then using the same method as with international cities. Technically it was hours of work wasted, but hey, I learnt a few things too.

[Groundhog]

Fully functional UI:


(Very) WIP upgrade to the above UI:

[Groundhog]

My initial plan in my earliest posts were for the sim to be browser based, rather than an installed, UI-type program. The reason I went with a regular software GUI was mainly because I figured going browser/web-based would be too difficult as I have no experience with it outside of simple HTML. With all the difficulties I was having getting my UIs to function as I wanted them to, I revisited the web/browser idea.

Python has a number of web frameworks available, and the two I experimented with were Django and Flask. Django is very simple - you can have a decent blog-type site with an admin page is no time at all, and it's pretty perfect for that kind of setup nearly out of the box. Trying to tweak it into something closer to what I need proved a bit more difficult, so I tried Flask.

Flask is a lot more lightweight than Django out of the box, and has a ton of extensions to allow you to plug in" features like login pages, admin pages, database support, etc. as/if needed. It also feels more "Python" native to me than Django did, and I was able to create a pretty simple site after a few days of reading tutorials and tweaking.

I'm far from an expert, but after one weekend I feel more comfortable with Flask than I ever did working with Qt UI forms, so that's the direction I'm going to be moving forward with.

[CraigSca]

Interesting. I have a book that I've been looking at that's devoted entirely to Qt. Seeing that you were using it, too, I considered it a no-brainer. Will have to check out Flask - I had a friend recommend to me CherryPy as the framework du jour. So many choices...

[Groundhog]

Let me put it this way - if I were building a desktop application in Python, I would use Qt in a heartbeat for the UI. Coupled with Qt Designer it makes designing forms and adding widgets a breeze, and a lot of the difficulties I had with it would have been solved if I had a book rather than relying on internet tutorials.

The big thing for me though is I wanted a UI that looked a bit more modern and I spent a good 3 days designing a combobox that worked like the ones in FM - a dropdown selection, coupled with left and right arrows. I ended up with a hackish widget that worked but wasn't close to what I was shooting for, and the whole time I was thinking to myself that I could do this in html in no time at all. I've seen some great UIs done in Qt, especially some of the 3D modeling apps I've seen, but that's way beyond me.

I did actually download CherryPy but I got so caught up in this detailed Flask tutorial that I never got a chance to try it: http://blog.miguelgrinberg.com/post/...-i-hello-world

[Groundhog]

A quick look at my first attempt at a web UI. The only part that is functional as far as actual database calls are concerned is the blue team name/info box, but I'm really just trying to get a feel for the layout at this stage. Eventually the colour of the team info box will be set per team (ie. Celtics green/white, Timberwolves blue/white), and I'd also like some fast-navigation links at the top above the team box, like: Leagues > NBA > Rosters > Cleveland, as well as an export to csv button below the roster.

[Groundhog]

Updated:

[CraigSca]

Originally Posted by Groundhog

Updated:

Omg, so cool!

[Groundhog]

The best part is that it took me about 4 hours to put that together - most of that time spent learning how to use the Bootstrap css and brushing up on html. For me to design something like this in Qt, while no doubt possible, is just way beyond me right now.

Of course, I still need to get all those tabs actually doing something... Tonight I'm going to work on loading the roster info from the database, and hopefully start on the basic player page, and having a link to it from the roster page.

[GoldenEagle]

Are you using Flask as your web framework? I know you mentioned it, but I am not sure is that is what you settled on or not.

[Groundhog]

Yep, I've been using Flask. It's pretty simple for the basic stuff I've been using it for - different URLs pointing to different templates and database queries, and the harder stuff I had some troubles with - authentication/authorization in particular - I've shelved for now.

[Groundhog]

Once again I took for granted how difficult something, in this case marrying up the Jinja2 web templating and Flask web frameworks, would be.

What started as 'Groundhog learns Python' is now more like 'Groundhog learns Python, the Flask web framework, Jinja2 web templating, HTML, CSS, and SQL'.

On the Python/basketball simulator side of things, although there's still a long way to go, it's been awhile since I have struggled to come up with a way of doing what I wanted to. It's really just plugging away, picking up small bugs here and there, and refining a lot of the stuff I coded at the beginning. I have a big list of 'TO-DO' code blocks that I cross off as I get to them, but it has taken a back seat to learning all the other stuff, as I tend to find that each component is usually a few weeks of work in itself to get a handle on, at best.

I'll have some more screenshots of the web interface tonight. I have a fully functional roster page that pulls its data from the database. I created a couple of NBA rosters with info, ratings, and stats. One thing that I'm not happy with but haven't found a great solution for is having the roster page not re-fresh/reload from the database each time a nav button is selected. Ie. clicking the 'stats' button in the pic above doesn't just load the bottom section of the page with data already queried, it refreshes the entire page and queries just the data needed for that one section. It's not a big deal when I'm hosting it locally and running queries on my lonesome as it loads instantly, but I'm not sure how it would perform on an actual webserver with multiple people running queries.

[CraigSca]

Looking forward to the update. Because of your work, I'm now vested in learning Flask, HTML, CSS. My goodness, what a pain. It's not easy being a single programmer anymore.

[Groundhog]

Since we've got some folks who are interested in Flask, I might break down quickly how I put this together, with the disclaimer that it's probably not the best way to do it - it's just the way I got it to work.

#1: My base template that, while also providing the main header and navigation icons, also sets up the css files for all the child templates. The selections available here are determined by variables, with more options available for users that are logged in.

#2: The rest of this page is all the one template, starting with a 'well' from the Bootstrap CSS file containing the team information. The background/foreground colours are defined in the database per team, and the logo filename is built by searching for 'leaguename_team_name.png', and showing a generic logo if not found. The default Bootstrap settings make this div class too spread out, and I will be reducing the distance between the text, as well as decreasing the size of the well box.

#3: Nav tabs, with the current page triggering which nav tab is 'active' (selected). Clicking on any of these options loads a different link, which actually points to the same template html file as above, but with different variables being triggered to present a different view and setting the appropriate nav buttons to 'active'.

#4: As above - loads the same template html at different URL, which leads to different variables/SQL queries passed to the template to present different information.

#5: Dynamic links using the player's unique ID in the database to (eventually) point to the individual player pages.

[Groundhog]

I took a break from the web stuff today to start the initial work on the finance side of the sim.

I want to include at least two different type of financial systems, one that mirrors the NBA (as close as possible, anyway), and one that tries to emulate a generic European-style of non-salary cap roster building, that scales per the quality of the league. The overall idea is to not focus on all the different individual finance rules that exist around the different basketball leagues, but to implement one system that is consistent across all non-NBA leagues, and scales neatly up and down.

Each nation is rated in a number of categories, like economy/popularity/talent, and these ratings determine arena sizes, ticket prices, average salary range for local players, etc. Cities within each nation are ranked by population size which means the biggest cities will tend to have the biggest arenas, but there is a random element to it.

Ticket sales, both in the domestic leagues as well as the Euroleague, will provide much of the income, but there will also be a 'misc income' category. For 'fluff' purposes it would cover sponsorship, concession funds, jersey sales, etc., but in game-terms it's the x-factor I will use to help keep budgets in line with the type of numbers I'm after.

On top of the basic finances, each team has an owner with some willing to provide more money out of pocket to finance a team than others - again this scales with the league quality. I'd like rare cases of teams like CSKA who are rolling out some crazy-high salaries compared to other top teams in Europe, and in my sim this would be reflected by a wealth owner offering something ridiculous like 300% of a usual team budget.

I researched as many import rules as I could for the different leagues, as well as restrictions on how many nationals are needed in some leagues, and for those that I couldn't discover I used an average. What I don't want is top teams in Spain having a ton of money used on the top international players, and then one or two Spanish players if any - this way they are forced to have 6 (from memory) Spaniards, and only 4 non-Europeans.

Also to help keep the leagues looking realistic as far as roster makeup goes is the fact that players will expect more money to play in a foreign league, making it cheaper to get a similar player who is a national than a foreign player, and players from higher-talent nations will expect more on top of that to play in a lower tier league.

Top-flight local talent from each nation will still expect top-flight money, but the range of wages for the middle-tier to low-tier talent is defined as per the quality of the league.

All of the above is currently just a series of dictionary entries in a python file, but considering this morning I had not really given this side of the sim any thought, I feel like I've got a pretty good feel for how it's going to work now.

[Groundhog]

Bought this yesterday to help with the Flask side of things: Flask Web Development: Developing Web Applications with Python: Miguel Grinberg: 9781449372620: Amazon.com: Books

Written by the same guy who put together the Flask tutorial I linked above. Two chapters in and already it's been a huge help.

[Groundhog]

Add Java to the list of things to learn. I've always been hesitant to learn java because I deal with so many crappy java applets every day at work, but it seems like the easy solution to cutting down on the amount of templates required.

To use the roster page as an example again, clicking through to the roster page now loads all the tables needed for each of the Info / Stats / Ratings / Salary nav pills. Using javascript I hide the tables excluding the default selected (Info). Clicking a different nav pill sets the icon to active, hides Info, and reveals the appropriate table. This would mean a slightly largely db query as the page loads, but significantly less reloading when navigating the tabs.

I'm going to experiment with loading ALL the info for the team, including the top nav tabs (Roster / Staff / Team Info). This would mean a lot more hiding/unhiding java scripting logic as well as potentially longer load times depending on how much info is included on these other tabs, but browsing through the different tabs would be instantaneous once loaded.

I also made some changes to the navigation menus and style based on some templates found online. I'll post some more screenshots when I've cleaned it up a little bit.

[Young Drachma]

You're making great progress! I haven't checked in in a while but looking now and you're getting places!

[GoldenEagle]

I think you are confusing Java with JavaScript. They are two completely separate languages.

Java is what I write code at my job. It is more for enterprise back-end type stuff.

Javascript is more for the web. You will definitely need to learn for a project like this. If found the website javascriptissexy.com useful, but I think he has stopped updating it.

[Groundhog]

You are completely correct.

I've really just touched on jquery and datatables right now as far as javascript goes (along with some of the simpler bootstrap-specific stuff), which is pretty simple for putting together the different views on the roster page. I think the next challenge will be working out how to link variables between Python-->Flask-->Jinja-->Java-->Flask-->Python.

[GoldenEagle]

I would suggest looking into JSON for that.

Which will be another thing to learn

[GoldenEagle]

Also, I thought you might find this interesting:

Exploring NBA Data with Python

[Groundhog]

That's a really good read actually. Looking forward to playing around with that tonight.

[Groundhog]

Spent the last week focusing solely on the basketball/python aspect of this project. For the fourth or fifth time I've re-designed the main game loop entirely, and I've now got something that is consistent and I don't envision having to change it again.

I understand Thomson's rule for first-time telescope makers now, as changing the format of the loop means rewriting large portions of the code, especially keeping track of how variables are passed around the loop. I spent as much time in Visio and Google's Draw as I did in the notepad.

In case it's of any interest to anyone, this is a quick summary of the new structure:

1. Pre-loop
When the script is launched, it loads the team rosters and information. Right now the teams are pulled from the db with the team id # being coded in, but eventually the simulation code will be inside a Python Class (most likely), and passed the team IDs based on the schedule.

The league rules are also queried from the database to get things like amount of periods, period length, max fouls, 3pt shot enabled, etc.

If the DEBUG flag is set to True, the loop will be passed to whichever event I want to simulate. If False, it will print the game introduction text, before launching the game loop, pointed at the opening jumpball.

2. Game Loop
The main loop is a 'while my_variable == True' loop that keeps the loop alive until the game is finished. Underneath that, the top-level loop control is done via a variable named 'loopstate'. Each 'loopstate' else/if block is made up of related sub-else/if blocks for different events.

For example, there's a 'loopstate' named "action_midstates". Underneath this else/if block is the logic for all of the calculations to be made prior to the next step of the sim - such as subtracting time from the clock, checking for injuries, calling timeouts, etc. Once the loop is passed to "action_midstates" the block is also passed a variable named "iterator_logic" to determine which of these midstate events to simulate for that situation. For example, if there is a defensive rebound made, the loop will be passed to "action_midstates" with an "iterator_logic" value of 'defensive_rebound', which will calculate things like updating the team with possession, a check for time-outs, desperation shots, etc. but not things like substitutions that wouldn't make sense in this situation. I have a separate config file that defines all the midstates to be simmed per iterator_logic value, which makes it really quick to re-order or change.

One of the midstates will check for the end of the period, and once the final period has concluded, the top-level While loop will be set to False.

All other loopstate blocks work roughly the same way, with sub-else/if blocks that point to more specific events. There is a block for events such as shots/rebounds, for the playbook iterator, and for the strategy decisions. The last two are very WIP.

3. Post-game
Not yet implemented, this will simply write the results to the database.

[JetsIn06]

I don't think a thread has ever made me feel so lazy. I love this, it's inspiring...keep it up!

[Groundhog]

Originally Posted by Groundhog

and I've now got something that is consistent and I don't envision having to change it again.

Tsk tsk tsk... Groundhog, when will you learn.

I was working my way through the tutorials hosted on the excellent Program Arcade Games With Python And Pygame site. Although it's geared towards developing skills using the python module 'PyGame' to make graphical games, it has some good theory around class objects, and in particular converting programs from the basic top-to-bottom python script to python classes.

This is the first time it really clicked with me. It's one thing to read about classes in books with examples on basic basic inheritance and variables 'x' and 'y', but to see how a program can be transformed from a script to a class in practice really made all the difference to me.

The good news is that nothing is really wasted re: the restructure I did. It's just now moving things around a little and changing the way my variables are stored. Although the later is quite a bit of work really as far as changing references throughout the code, a lot of the headaches I had passing these variables between my main game file and the files I used to store commentary and other common functions will become a thing of the past.

It's also simplified the structure of my game loop, with it now centering around each possession of the game, rather than one big loop that begins at opening tip, progresses through each phase of the basketball game until the end of the last period.

[Groundhog]

I should also add that I'm leaning back towards making this a desktop application rather than web-based. Not so much due to difficulty, but I think it's a bit too ambitious at this stage.

I do really enjoy working with Flask though - it's something I would consider doing for a career to be honest.

[CraigSca]

Just so you know - make up your mind with this stuff! There are some people around here that are following what you're doing and letting you make their decisions for them for their own projects

Would love to hear what tools you'll be going back to for the desktop.

[muns]

Originally Posted by CraigSca

Just so you know - make up your mind with this stuff! There are some people around here that are following what you're doing and letting you make their decisions for them for their own projects

Would love to hear what tools you'll be going back to for the desktop.

This gave me a good laugh!

Great read though, and nice work Groundhog!

[Groundhog]

Originally Posted by CraigSca

Just so you know - make up your mind with this stuff! There are some people around here that are following what you're doing and letting you make their decisions for them for their own projects

Would love to hear what tools you'll be going back to for the desktop.

Yeah believe me, I get it. I think the usual cycle is: 1) discover new technique/module/framework. 2) Get excited, spend weeks learning it. 3) Realize that it's a lot more involved than I first thought, as far as getting it to do exactly what I want. 4) Concentrate on the pure-python sim-stuff once again.

The positive side is that I feel like I haven't actually wasted any time, either. The Flask/Jinja2 framework, and the bits and pieces of javascript/jquery and datatables I've learnt, have really impressed me and whatever form the sim takes it will need to generate web content.

Qt would still be the choice as far as desktop interfaces go, and there are books on Python & QT that I'm just going to have to push through. IMO there's just nothing else (free) out there that makes better looking UIs for python programs.

As far as your own programs go, nothing has made me doubt the choices I've made so far - Python for an easy-to-learn yet still powerful programming language, Flask for web applications, and Qt for desktop applications.

[Groundhog]

I spent the last couple of days working on a neat little debug module to make it a lot quicker to test if everything is working as it should, by scripting a bunch of scenarios for different events, which will then be simulated and checked. Doing this manually each and every time I made a change was just taking way too long.

First time I ran through the FT debug I encountered a rare bug that caused a guy to shoot FTs forever... I'm calling it the 'Josh Smith bug'.

Here's a quick view of some of the output:

Spoiler

Beginning debugs...

Beginning 'action_event' states...

Opening jumpball:


Opening jumpball.
------------------
T. Mozgov and J. Noah are in the middle for the opening tip.
The ball is up.
T. Mozgov tips the ball to K. Irving, possession is with Cleveland.
possession_begin_state: tip-middle

Fouls:

Fouls: Offensive
----------------
Off. fouler location: 9, next inbound location: inbound-opposing-sideline
Turnover assigned.
Team turnover assigned.
PF assigned.
PFA assigned.

Fouls: Defensive, no shooting
------------------------------
Ballhandler location: 6, next inbound location: inbound-own-sideline
PFA assigned.
PF assigned.
Team PF assigned.

Fouls: Defensive, shooting
---------------------------
PFA assigned.
PF assigned.
Team PF assigned.
Next possession 'free_throws'.

Fouls: Defensive, penalty fts
------------------------------
PFA assigned.
PF assigned.
Team PF assigned.
Shooting foul triggered by TF count.
Next possession 'free_throws'.

Freethrows:

FT Type 1: Standard FT, 1 shot.
-------------------------------

K. Love is at the line shooting one free throw.
The shot is good.
possession_begin_state: inbound-opposing-baseline
shooter points: 1, FTM: 1, FTA: 1

FT Type 1: Standard FT, 2 shots.
---------------------------------

L. James is at the line shooting two free throws.
The shot is no good.
The shot is good.
possession_begin_state: inbound-opposing-baseline
shooter points: 1, FTM: 1, FTA: 2

FT Type 1: Standard FT, 3 shots.
---------------------------------

D. Rose is at the line shooting three free throws.
The shot is good.
The shot is good.
The shot is no good.
rebound triggered.
possession_begin_state: free_throws
shooter points: 2, FTM: 2, FTA: 3

FT Type 2: FT no rebound, 1 shot.
----------------------------------

J. Butler is at the line shooting one free throw.
The shot is good.
possession_begin_state: inbound-own-sideline
shooter points: 1, FTM: 1, FTA: 1

FT Type 2: FT no rebound, 2 shots.
-----------------------------------

M. Dunleavy, Jnr. is at the line shooting two free throws.
The shot is good.
The shot is good.
possession_begin_state: inbound-own-sideline
shooter points: 2, FTM: 2, FTA: 2

FT Type 2: FT no rebound, 3 shots.
-----------------------------------

P. Gasol is at the line shooting three free throws.
The shot is good.
The shot is good.
The shot is no good.
possession_begin_state: inbound-own-sideline
shooter points: 2, FTM: 2, FTA: 3

FT Type 3: one-and-one, 1 shot (potentially).
----------------------------------------------

K. Love is at the line for the 1-and-1 opportunity.
The shot is good.
The shot is no good.
rebound triggered.
possession_begin_state: free_throws
shooter points: 1, FTM: 1, FTA: 2

[Groundhog]

Been awhile since my last update, but this isn't dead. I was overseas for a month and a half, but the past week or so I've really kicked back into gear. Nothing sexy to show off, but I've made a couple of big changes to the structure of the sim that solved a few problems I was having around the timing of the functions that simulate the different events vs. the display of the play-by-play text.

[muns]

just checking in

I know being off hurts my motivation for projects, but wanted to see what was going on if anything.

[Groundhog]

Thanks for checking in - glad to know folks are still following along.

My process the past couple of weeks has been to alternate a few days at a time between the code that makes up the simulation engine, and working on other odds and ends. The past couple of days it's been the UI - something I'd put aside previously after the work I posted above.

Outside of this project I've been working on a BBCF -> FOF draft file generator with a GUI and that's helped me get comfortable with the Qt UI framework in Python via PySide.

I'm trying to come up with something that combines the clean look of the web-based UI screens I posted above with my favourite 'text sim' UI currently - Football Manager. As much as I like FM's UI, I still find it a bit cluttered - it's hard to avoid really, given the sheer amount of info and screens buried in the title - so I've been trying to simplify mine.

It's all still very WIP at the moment, but I'll post some screenshots tonight.

[Groundhog]

Here's a peek at the roster page. The buttons are obviously placeholders. The roster info and print buttons will have rounded edges and maybe be images rather than text on a widget, and Menu 1 through Menu 3 will be images of some kind too.

The large blank panel will display the roster info... once I get my head around Qt Table Models, anyway.

[muns]

looks really good. Nice work!

[Groundhog]

And now with a bit of functionality!

[Young Drachma]

Love that you're still working on this. Very awesome and good progress!

[Young Drachma]

Originally Posted by Groundhog

I was so sick of using excel that I decided to create my first UI for the sim, the editor screen for player generation:

Dola, I love this. I've wanted a game to have something like it for ages native and not within a third-party app.

[Groundhog]

Me too!

I'm working on adding the above into the new UI right now.

I spent sometime yesterday scrolling through the fonts on my PC to find something that works well with the banner-type menus. I finally found one that looked perfect, and was not surprised to see the font was named 'FBB'.... d'oh.

One thing I've really come to love about Qt is its use of StyleSheets. As with css in html, these really save a lot of time during the creation of UI elements, as well as making things like updates and customization a real breeze.

Every element on the screen is configured, from shape to colour to font, via the use of these StyleSheets within Python, rather than Qt Designer, which are then stored in their own 'css'-type file within the project.

The idea would be that, one day, some of the folks out there who are far more creative than me would have no trouble redesigning the UI if they wished.

[Groundhog]

The semi-functional league generation settings screen - interested to hear any thoughts on the overall UI look:

[Groundhog]

WIP of the player profile screen - with and without player profile image detected:

[tarcone]

While this is mostly a foreign language to me, I have been following. I'm very interested in the end product and would be a play tester if needed.

Good job. This has been awesome to watch.

[Young Drachma]

Pre-pre orders.