chicken-sdl2 0.2.0 Released

Screenshot of a graphics demo showing waves, the moon, stars, and constellations.
Screenshot of “The Sea and the Stars”, a new demo program using chicken-sdl2 0.2.0.
Today I released version 0.2.0 of chicken-sdl2 (aka the sdl2 egg).

chicken-sdl2 provides CHICKEN Scheme bindings to version 2 of the Simple DirectMedia Layer (SDL) game development library.

Highlights of this release include:

  • Support for 2D accelerated rendering (renderer and texture)
  • Support for hints (configuration variables)
  • Support for most SDL 2.0.4 features
  • Efficient color, point, and rect operations
  • Performance improvements
  • Improved integer type checking
  • Miscellaneous other changes

For more details, please see the CHANGELOG.

Many thanks to Kooda Loutre and Kristian Lein-Mathisen for submitting suggestions which have been implemented in this release. :)

Lisp Game Jam Post-mortem

I recently participated in the 2016 Lisp Game Jam, an event where participants had 7 days (later extended to 10 days) to create a computer game using a dialect of Lisp, a family of programming languages. This is a “post-mortem” of that experience, in which I discuss what went well, what could have gone better, what I learned, and so on. Continue reading Lisp Game Jam Post-mortem

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.

Lisp Game Jam Log #9

My game jam entry is coming along nicely, and the deadline has been extended by 3 days, so I have some more time to polish it and write about it.

Screenshot of a game with five colored characters and many coins and gems scattered around the level.The “engine” parts of my game are mostly finished now, so I have been working on implementing and polishing the gameplay mechanics. I now have fairly satisfying player movement, random spawning of players (and respawning, if they fall off the screen), and random spawning of treasure. For demonstration purposes, I spawned all 5 players in this screenshot, although there are currently only controls available for two of them.

Player spawning is based on tile labels. Each tile in a level can have a 3-character label which assigns it some special behavior. In the case of player spawning, there are six labels: pl1 through pl5, which are specific to players 1 through 5, plus pl*, which can be used by any player. At the start of the game, the algorithm will try to put a player at a spawn point that is specific to that player, but if it can’t find a specific spawn point, it will fall back to selecting one of the general spawn points. (And, in the case that the level has no spawn points at all, the player will spawn in the center of the level.) If a player falls off the screen, they will be moved back to a random spawn point, either specific to that player or a general spawn point.

The treasure spawning system is similar, but more complex. There are five labels, tr1 through tr5, that can be applied to tiles to mark the tiles as treasure spawn points. The number specifies the “grade” of the spawn point, which affects what kinds of treasure appear there, and how often. Lower grade spawn points spawn mostly coins, but very often. Higher grade spawn points spawn mostly gems, but less often. The low-grade spawn points are meant to be scattered around the level in easy-to-reach places, with a few high grade spawn points in hard-to-reach places. You can see this in the screenshot, where the gold coins and green gem are in more difficult and perilous positions than the copper or silver coins. This follows the game design principle of balancing risk and reward — higher risks offer higher rewards.

The algorithm for spawning treasure first finds all the tiles in the level that have a label indicating it is a treasure spawn point. Then it shuffles that list into a random order, and begins iterating through the list, separating it into two piles. If the tile passes a random check (based on the chance specified for its treasure grade), the tile is put into the “chosen” pile. If the tile fails the check, it is put into the “rejected” pile. The algorithm terminates if enough tiles are chosen, but if it gets to the end of the original list and doesn’t have enough tiles, it will repeat the process using the “rejected” pile, giving those tiles a second (or third, etc.) chance to spawn treasure.

It is possible that a level might not have any labelled treasure spawn points, so as a fallback the algorithm simply chooses tiles at random, and spawns low-grade treasure there.

It was not strictly necessary to make the algorithm so complex. Most levels should already have relatively few high-grade treasure spawn points, so high-grade treasure would naturally be more rare (fewer tiles = less chance of being selected in the shuffle). But, this algorithm will allow me to tweak the odds for gameplay balance, and it was fun to write the list traversal code.

I have not yet programmed entity/entity collision, so it is not yet possible for players to pick up treasure. That will be my next step. I was previously thinking that treasure would disappear after a few seconds, so that the treasure is constantly circulating, encouraging the players to move around the level. But for simplicity, I will probably make the treasures remain until a player picks them up, then immediately spawn another treasure to replace it.

Another thing I did yesterday was create a highly-commented template level, to help people get started making their own level. It is not yet possible to choose a different level, but I will definitely at least add a command line flag to choose the level. If I have time, I might add a GUI to select the level.

I noticed last night that there is a performance issue with my game. While you play, the game gradually uses more and more CPU, and its framerate gradually gets choppier and choppier. I suspect that this is caused by the app putting pressure on CHICKEN’s garbage collector, since many temporary rects are being allocated and thrown away during the collision detection, which occurs hundreds of times per second.

Unfortunately I’m not experienced with profiling CHICKEN code, so I am not completely sure that my intuition is correct. But, I’ll try to reduce and reuse the rects during collision detection, and see if that helps. If I can’t figure out what the problem is, then I guess I’ll make it part of the gameplay: see which player can collect the most treasure before the game’s framerate becomes completely unplayable! :P

Lisp Game Jam Log #4

Screenshot showing a game level with two characters, a coin, and a gem.Today I started on the physics engine for my game. I have implemented the entity record type, which represents dynamic objects like players and items, and the body record type, which represents the physical attributes of an entity, such as its position, velocity, acceleration, dimensions, and mass.

CHICKEN Scheme has several object-oriented programming libraries that support inheritance (I even created my own for fun a few years ago). But so far, I have just been using basic Scheme record types (structures with named slots), and using composition instead of inheritance.

In other words, instead of having the entity type inherit position, velocity, etc. attributes from the body type, an entity has a slot which holds a body. And instead of having a player type and a coin type and a gem type which inherit from entity, an entity has slots to hold other objects which define its appearance and behavior. I’m not opposed to using inheritance when the need arises, but so far while making this game I have not needed it.

Today I also wrote a simple physics update function (apply the acceleration to the velocity, then the velocity to the position), and I now have moving player characters on the screen. There is no collision or user input yet, but by setting the initial attributes of the characters, I can make them fly through the air in a parabola, then fall down off the bottom of the screen. I also added a coin and a gem entity to the scene, just for kicks.

I added user-customizable scaling for the window, since the graphics are a bit small (each tile is 21-by-21 pixels). I’ve shrunk the screenshot in this post so it wouldn’t be too wide, but you can click it to see the full version. The default scale is 200%, but users can edit the settings.scm file to change that if you want. In the future, that file will have other settings like the keyboard/joystick bindings.

The settings file, like the level file, is just a collection of s-expressions. I’m using CHICKEN Scheme’s built-in read-file procedure, which reads (but does not evaluate) all the s-expressions in a file and returns them as a list. This is probably not super secure, since users might be able to exploit the reader in some way to inject code, but it sure is convenient. Besides, security is not a high priority in the heat of a game jam.

My next step is to add detection and resolution of collisions. If this were a shorter game jam, or if I had more complex scenes, I would definitely just use a pre-built physics engine like Chipmunk. But, I think I have enough time to implement a good enough physics engine to handle a simple platformer game like this.

P.S. The in-progress source code is available.

P.P.S. The sprites are from Kenney Game Assets. I got them from donating about a year ago, and they are licensed CC0 public domain. An older version of the same sprites is available with no payment required.

Lisp Game Jam Log #1

The January 2016 Lisp Game Jam officially started earlier tonight. I haven’t participated in a game jam for several years, and I’m excited. Game jams are exciting (and stressful) in general, but I’m also excited because this is my first jam using a Lisp dialect, plus it is an opportunity to use the CHICKEN Scheme bindings to SDL2 and related libraries, which I have been working on for the past several months. (I’m also excited because at least two other people are planning on using my bindings for the jam, which is a nice feeling.)

This game jam does not have a prescribed theme, so I’m free to make any game. I’ve been pondering for weeks about what kind of game I might make for the jam. My goal is to produce another example game for the bindings, so I want the result to be clearly organized, well documented, and to demonstrate the capabilities of the bindings. In particular, I want to try to push the boundaries of performance. My previous game library project, Rubygame, struggled with raw performance, partly because of the performance limitations of Ruby in those days, and partly because I didn’t put much effort into optimization. So, I’m keen to see what I can achieve with CHICKEN Scheme and these bindings.

Thinking about what type of game I’d like to make for the jam, I had two main ideas: a scrolling space shooter à la Tyrian, or a platformer à la Mario Bros. I also briefly considered a Harvest Moon-like RPG, but decided I wouldn’t be able to make it fun in 7 days, and the laid-back gameplay style wouldn’t push any performance boundaries.

Between the space shooter and the platformer, the space shooter would be a more interesting example, because I could try to achieve solid performance while having hundreds of bullets and ships on screen at the same time, and it could use the function bindings I recently added for 2D accelerated rendering. But, those bindings aren’t actually released yet (they are scheduled for version 0.2), so it wouldn’t be as easy for people to install the bindings and play the game. So, I am going to make the platformer game for this jam, and then make the space shooter at some later date.

This game jam allows us to use preexisting free assets (images, sound, music), so to make things easy for myself I am going to use a lot of assets from the Kenney Game Assets pack. (You have to donate money to get the assets from the official store, but they are licensed CC0 public domain, so no doubt they are available somewhere for free.)

In terms of gameplay, I’m thinking the game will be a rowdy local multiplayer game, where players compete to collect the most treasure, like the old Super Mario Bros. Battle Mode. At the most basic level, it could just be treasure periodically appearing at random places on the level, and the players scrambling to reach it first, with no real interaction between players. If I have time, I could add various ways for the players to interact and interfere with each other: bouncing and bumping into each other, triggering traps, throwing items, etc.

This game design is simple and flexible enough that I’m confident I’ll be able to complete something fun during the game, especially since we have 7 days. I will probably try to include 2 or 3 built-in levels, and have a simple text-based file format so that people could create their own levels.

chicken-sdl2-ttf 0.1 Released

Screenshot of the chicken-sdl2-ttf demo program, displaying the text "Hello, World!" three times. Last week I released version 0.1 of chicken-sdl2-ttf (aka the sdl2-ttf egg). This provides bindings to SDL_ttf 2, the font rendering library for SDL. This library is compatible with chicken-sdl2, which I released a couple weeks ago.

SDL_ttf is thankfully a fairly small library, so I was able to create and document complete bindings to it in less than a week, in advance of the January 2016 Lisp Game Jam, which has just started a half hour ago.

My plans now are:

  1. Create a game for the game jam!
  2. Release chicken-sdl2 0.2 (the main new feature is 2D accelerated rendering).
  3. Create bindings for SDL_mixer, and possibly SDL_gfx.

chicken-sdl2 and chicken-sdl2-image 0.1 Released

Today I released two new library bindings to make it easier to develop games with the CHICKEN Scheme programming language:

CHICKEN Scheme has excellent FFI support, so it was previously possible to use SDL2 from CHICKEN Scheme — possible, but not convenient or straightforward. I have made an effort to create programmer-friendly, convenient, thorough, and well-documented bindings. These bindings take care of the annoying low-level C stuff for you, so you can focus on making your game.

Although the version numbers for these libraries are only 0.1, they are ready to start using now. Some features have not been implemented yet, but it is already possible to create many types of games, even 3D games using OpenGL (when combined with the gl-utils or opengl egg, for example). Several demos and example programs are available to help you get started. Large backwards-incompatible changes are unlikely, but there may be small tweaks and fixes to the API if problems are discovered. There may be some bugs, but they will be fixed promptly if you report them to the issue tracker.

I also intend to eventually create bindings for other libraries, such as SDL2_ttf (for text rendering), SDL2_mixer (for sound effects and music), and SDL2_gfx (for shape drawing and image transformation).

In related news, there is a 7-day Lisp Game Jam coming up the first week of January. I will be creating a new example game using these bindings, and hanging out in the IRC channel (my handle is “jacius”) to answer questions about the bindings, CHICKEN Scheme, and SDL in general.