Performance Gains and Code Refactoring

Good news to everyone who was running into general slowdowns and unresponsiveness in Lab Rats 2! Yesterday and today I focused on refactoring two major sections of old code and have had great success with it. TL;DR: you will see a 5 fold performance gain and future work with drawing characters will be easier for me. But I like writing about programming, so stick around if you want to know more about the details.

The first rewrite was for the section of code that actually tells Ren'py to show an image to the screen. Previously each image that made up a character - their body, hair, and each clothing object on them - was called and told to draw itself to the screen. By ordering these calls correctly the collection of images would be layered and end up forming the characters sprite. There were a couple of problems with this system. If I wanted to apply a change to the character sprite (say, a simple sprite animation/distortion) I needed to apply it separately to each image and ensure somehow that all of the images remained in synch with each other. Additionally, Ren'py needed to store a bunch of independent small images, which made sprite level operations computationally expensive because they were repeated for a lot of pixels that ended up being obscured by images layered above them.

The new drawing system now passes all displayable up to the Person class layer. When I call the_person.draw_person() all of the images are gathered together and flattened into a single image, then drawn to the screen. This means I only have to worry about manipulating a single image, which is both faster for Ren'py and simpler for me. This change will not have produced any observable effects while playing yet, but it will make changes in the future much simpler and let me use a wider range of sprite transformations.

The next major change was to how images were stored internally. Previously each image for a character's body, clothing, hair, and so on was stored as an instance of the Ren'py class Image. All instances of a type of clothing, hair, etc. pointed towards a single object that stored all of the Image instances which ensured there was not a massive duplication of data. Unfortunately Ren'py has a hard time understanding how to save data structures like this and would duplicate the Image array for every character while it was saving. Image loads and stores the image file so it can be displayed quickly, but it takes up a lot of space which resulted in very slow loading (and rollback, which uses the same fundamental saving system). This saving and rollback lag got more pronounced as the number of characters in a game rose.

Now the filenames for characters are stored instead of actual Image instances, and an Image object is created on demand when something needs to be drawn to the screen. A test with a ridiculous number of characters (1717) in the new system suggests each character takes up about 6.2kb when being saved. In the old system each character averaged 30kb. This suggests a five fold increase in performance wherever saving and loading characters is concerned. In my test game beginning and end of day turns took about four seconds to process and rollback was impractically slow, but the other elements of the game functioned without any lag. I will be looking into how to improve rollback speed in the future.

This about wraps up my look at the lower level code of LR2 for this update. My next goal is to add in new business policies and serum traits.