Lisp Game Jam Log #10

Screenshot of the finished first game level. Yesterday I did quite a bit of performance tuning, implemented the ability for players to collect treasure, various gameplay improvements, and a command line flag to specify an alternate level file to load.

I wrote in my last post about how the game’s performance slowly degrades over time, probably due to pressure on the garbage collector from temporary rects created during collision detection. I did some basic performance profiling using CHICKEN Scheme’s built-in profiling support (the -profile compile flag and the chicken-profile utility program), which provides a table of each procedure that was called, how many times it was called, how much total time was spent in it, and an average time spent in it. This by itself didn’t definitively tell me that the performance issues were caused by creating too many temporary rects, but it did confirm that most of each frame was spent doing collision detection, and that make-rect was indeed being called many times. It also revealed a bug in chicken-sdl2 which impacted performance, the fix to which will be included in the next version.

I spent some time yesterday trying to improve the performance of the game, mainly by caching and reusing rects instead of allocating hundreds of temporary rects per second. This partially alleviated the issue, allowing the game to run much longer before degrading, but it hasn’t completely solved the problem. There is more work I could do to improve performance, but I am going to move on for the time being, and maybe come back to it at some future date.

Also yesterday, I added broad-phase entity/entity collision detection using bounding boxes, and the ability for players to collect treasure. The value for the treasure is added to the player’s score, although players’ scores are currently not displayed anywhere, so that is not apparent. When a player collects a treasure, a new treasure is spawned randomly. I tweaked the treasure spawning algorithm so that it won’t spawn on a tile that currently has a treasure or a player on it. I also made some tweaks and fixes to the balance and distribution of treasure.

Screenshot of a smaller, simpler game level. Also yesterday, I added a command line flag (-l FILE or --level=FILE) to specify an alternate level file to load. Shown here is the level template I included in the game to help users create their own levels.

The game window is sized to fit the level, so that levels can be different sizes. The number of treasures is also scaled to be 30% of the possible treasure spawn points, so that the gameplay balance doesn’t drastically change from level to level. Also, the game spawns the number of players specified by the level (default 2), so that hypothetically users could create a five player level and add key bindings for more players, although it would be rather difficult to fit five people around a single keyboard. Perhaps those programs that translate game controller input into keyboard presses would work here.

There is a lot more work that could be done on the game, but I’m pretty exhausted from over a week in game-jam mode. Tonight after work I might add a crude score display by updating the window title, but then I’m wrapping it up and submitting it. I might come back to it from time to time to update it and showcase more chicken-sdl2 features, but for now this is it.

2 thoughts on “Lisp Game Jam Log #10”

  1. I’ve been developing a game in Scheme for about a year now (Gambit-c, via lambdanative) and while I have some issues with iOS support, its been pretty great.

    I gather from this post you are having GC issues. I believe Chicken does not let you manually induce a GC pause. In Corpse Wizard (my game) I initiate GC after each user input, so that the GC pauses never grow very large. I also do some simple object pooling and other small things to minimize consing.

    If you keep having trouble with Chicken, you could try out lambdanative/gambit. I’d love to see more people using it.

    1. Thanks for the comment and the suggestions, vincent. CHICKEN does have a procedure to manually induce the GC, so I tried your suggestion. But, I did not notice much difference in performance when I induced the GC on every user input, or every frame, or not at all. CHICKEN’s garbage collection model is somewhat unusual, and I think it was already running fairly often anyway.

      It’s probably just a matter of my code being quick and dirty to finish on time for the game jam. I think if I spent more time cleaning up and optimizing the code, I could get the performance to acceptable levels. :)

Comments are closed.