1 Way I Improved Luck be a Landlord's Performance
When I write code, sometimes it's sloppy...okay, usually it's sloppy! But sloppy code is fine, if it works well enough. It's not worth spending a ton of extra time and resources trying to fix every minor issue with your code.
That having been said, many of the players who enjoy Luck be a Landlord have pushed the engine to its limits. Those limits being pushed often result in the game slugging to 1FPS. Many players will never reach this point, but the number of players who did definitely increased once achievements were added to the game. This is because a popular strategy is to farm achievements in endless mode, which led to a lot of performance issues the longer the run went on.
To keep the game running well for these players – and require less system requirements from the eventual mobile port – I implemented some optimization fixes that greatly improved the game's performance. Let's take a look at one of the multiple ways I made Luck be a Landlord run better.
In order to track down the exact cause of the awful framerate, I started by looking for things that laggy saves all had in common. These two aspects were present in every save I inspected:
- They were all in Endless Mode
- They all had multiple copies of every item in the game
Initially, this led me to believe that processing a large number of item effects was causing the lag. The calculations of how every item interacts with every symbol could lead to a lot of computing power being needed, right? However, I eventually realized that the game was also lagging while just idling on the symbol selection menu. This disproved my initial theory, since item effects aren't processed while spins aren't happening.
So, what was the issue? After a lot of testing, I noticed that having every item not check for hover events (whether or not the mouse cursor was intersecting it) caused the game's performance to improve in a noticeable way.
Unfortunately, items need to check for hover events, since the player needs to be able to mouse over them and see what their effects are at almost any time. Although...what if I just turned off the hover events for items that weren't on-screen? And this was where the Eureka moment happened!
I was dedicating the same amount of graphical resources to off-screen items as on-screen items. I was even having the engine spend resources on rendering them, while the player couldn't even see them!
After treating off-screen items differently from on-screen items (by dedicating far less resources to them), I noticed even more performance improvements. I eventually applied this logic to symbols as well, which resulted in an even more significant performance improvement! The idle lag on the selection menu was gone!
While this is probably an obvious solution to many programmers, I'm not embarrassed to admit that my code was suboptimal and that the fix was relatively simple. We all make mistakes, and maybe another programmer will read this and implement a similar fix in their game. That definitely makes writing this worth it, in my opinion.
This solution does a great job of mitigating – and sometimes eliminating – lag on most machines. There were still some major performance drops when spinning with specific items active (such as Telescope), but how I fixed that is a story for another day...
Until next time!
-Dan