Posts tagged "Technical"
JavaScript bundling for ZenGM, from 2012 to today
Every now and then I write a blog post about purely technical issues I've dealt with that have nothing to do with sports or video games. This is another one of those blog posts! For some reason I want to talk about JavaScript bundling - how it was in the old days when I first started working on Basketball GM; how it's changed over time; and what I'm doing now.
Investigating a tricky performance bug
Some people reported performance issues in my games recently. After debugging I found that there is indeed a serious performance bug in some situations. For example, viewing the standings page and auto playing a season took 3x as long as it did a couple weeks ago. That's pretty bad!
After looking in my past commits to identify exactly when the slowdown started, I found it happened when I upgraded @rollup/plugin-commonjs from version 21 to 22. That's a package used in compiling JS for production. Annoyingly, it's only used in production mode and not in dev mode, which makes it harder for me to notice a bug like this. But for this package to cause a slowdown is strange... it feels more like something that should either work fine or completely break, not cause a performance issue. So while I could stop here, switch back to the old version, and call it a day... let's go further.
No more size limit for exporting leagues
Previously, exporting leagues only worked for small leagues. After you played a couple hundred seasons, it no longer worked unless you deleted some historical data. A similar problem existed for importing large league files, although that was probably not noticed much due to the issue with exporting.
That's why there have been no updates the past couple weeks - I have been trying to fix all these import/export issues. It's actually pretty tricky, because it requires rewriting a lot of my code and also working around missing features and bugs in various browsers. But I think I am finally happy with it, so it is now released in version 2021.10.26.0638.
As an added bonus, you can also see progress bars when importing/exporting leagues, which is nice for large leagues:
Porting Basketball GM to TypeScript
This has nothing to do with basketball. Just programming. But I know some of you like hearing about the technical stuff that goes on behind the scenes - this post is for you!
Moving from Browserify to Rollup
This post has nothing to do with basketball or sports or video games. It's just about some technical details that helped me make Basketball GM run faster. If you're interested in that, keep reading :)
Owner messages revamp
The annual message from the owner has long been a quirky feature of Basketball GM. Each season, you'd get some strange message from the owner about your progress. By reading it, you could figure out how close you were to getting fired.
There were problems though. The messages got repetitive if you played a lot. Sometimes the messages were confusing and possibly buggy, like if you win the title and the owner is still not happy with how much you're winning.
Also the messages were often racist, sexist, or otherwise offensive. In my defense, those were all paraphrases of things our wonderful real life pro sports owners have said. But I don't think everyone got the joke.
Overall, it was not a great system. Finally, I have replaced it. Instead of the long old messages, you get a short message containing your overall performance, your performance in the past year, and a quick recommendation for next year. Also, you get a chart of your past performance, which looks like this:
So you want to write a sports simulation game
So you want to write a sports simulation game. Great! As someone who has written a sports simulation game, hopefully I can help you.
I get this question sometimes from people who know a bit of programming and would like to make a sports simulation game, but feel overwhelmed or don't quite know where to start. I know this feeling well. I wanted to make Basketball GM for a long time before I actually felt comfortable trying. Before that, I thought it seemed too complicated for me and I'd fail horribly if I tried.
How do you get past that? Well if I wanted an easy answer, I could say go look at the Basketball GM source code and be done with it. But that's a bad answer. If you don't know where to start and feel overwhelmed at the idea of making your own game, you'll feel that even more strongly when trying to understand my code. Basketball GM has been in development for years now, and the codebase has grown large and somewhat complicated. But at its core, a sports simulation game can be much simpler.
Ten year anniversary of the first commit to the Basketball GM code base
Check it out. Damn, nostalgia. I had just graduated from college and was trying to learn both Python and GTK+ (both technologies long since abandoned by BBGM) while pursuing this crazy idea of making a basketball management sim.
Looking at the code, some of it has totally changed, but other parts still have a direct lineage to the code today. For example, the ridiculously simple initial implementation of game simulation is not that different than the only slightly less simple implementation used today. The overall structure is the same, and many of the functions remain quite similar. Example:
Most Improved Player award
Basketball GM has long had awards every season - MVP, Rookie of the Year, etc. But Most Improved Player (MIP) has been missing for a while. That's because MIP is harder to compute than other awards. You don't need just this year's stats, you need prior years too. And you also need to understand context - is a player actually improving, or just recovered from an injury? Or maybe he's an established star coming off a bad season? Or maybe his numbers went up, but only because he got more playing time without really improving? It's complicated.
Basketball GM 4.0 technical details - caching, Shared Workers, IndexedDB/Promise interactions, Safari being a tease, McDonald's, and more
Google made me do it.
Basketball GM has always allowed you to open up the same league in multiple tabs, so you can easily view multiple different screens. This was originally implemented by running the entire game in each tab. Game data was always saved to disk via IndexedDB. And when an action resulted in a change to the data (such as playing a game, signing a contract, trading a player, etc), then a signal was sent to all other tabs telling them to update their data. This was kind of a crude approach, but it worked.
It worked, until Chrome started throttling JavaScript in background tabs. Their logic was, if you're not even looking at the page, do you really want it burning through your battery? It made perfect sense. Except for Basketball GM, it meant that game simulation would only run if you were looking at the tab you started it in. So if you clicked "Play until playoffs" and then switched tabs, it'd never reach the playoffs. Fuck!
When life hands you lemons, make lemonade. Since Google decided to totally invalidate the tradeoffs I had considered when designing Basketball GM, I decided to re-evaluate. I came up with two ideas:
Basketball GM is back on GitHub, but not quite open source
If you've been here a while, you may recall that Basketball GM used to be open source. Last year, I closed the source for various reasons. Now, I'm semi-opening it back up. My goal is to allow others to contribute to the development of Basketball GM without allowing a competitor to swoop in and just clone everything. I hope it works.
So please, take a look at the code and read the license. If everything looks enticing and you want to help make Basketball GM better, please get in touch! There are tons and tons of ways Basketball GM could be improved, in many different areas.
Powered by the KIRK HINRICH stack
The set of technologies used as a foundation for a piece of software is sometimes called a stack. The most famous is LAMP (Linux, Apache, MySQL, Perl/PHP/Python). A trendier option is MEAN (MongoDB, Express.js, AngularJS, Node.js). And there are tons more, mostly tounge-in-cheek jokes at the absurdity of reducing a stack to a catchy acronym (at least, I hope that's what they are). There is even the LeBron stack: LevelDB, Browserify, and npm. In Basketball GM, I use npm a little and I indirectly use LevelDB through IndexedDB in Chrome, but sadly it'd be quite a stretch to say I'm using the LeBron stack.
What stack am I using? Nothing coherent or well established. Just a hodgepodge of things that somehow happens to work. But that's just not a catchy answer, so I set out to find a cool name for my stack. The LeBron stack is a fun name, so I figured I could try to find another NBA-inspired name.
Development History
I wrote the first line of code for Basketball GM back in 2008, after I had graduated from college but before I started grad school. That code was C#, which I had never used before. My primary goal was to learn a new programming language and learn how to make traditional desktop GUI software, as previously I had only made software with either command line or web UIs. I was not sure if I was a good enough programmer to complete such an ambitious project, but I figured I'd give it a shot.