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 #6

Screenshot of a game level with several characters. The characters have colored lines drawn around and over them. Today I started on narrow phase collision detection. I also made many “under the hood” improvements to the code. And, I decided to simplify the game in order to save time.

First I’ll write about narrow phase collision detection (NPCD). In my last post, I wrote about broad phase collision detection (BPCD), in which the goal is to quickly detect possible collisions between an entity and a tile, or between one entity and another entity. After BPCD has narrowed down the possible collisions, NPCD performs more precise mathematical checks to find out whether or not a collision is actually occurring.

Zoomed-in screenshot of a character with colored lines drawn around and over him. The approach I’m using for entity NPCD is for each entity to have four “hitboxes”, smaller rectangles that are positioned on each side: left, right, top, and bottom. (The hitboxes are drawn in green in this screenshot, and the overall bounding box is drawn in red.) I can then check each hitbox to see whether it is colliding with a tile or other entity. Depending on which of the four hitboxes is colliding, the program will be able to calculate in which direction the entity should move in order to stop colliding. This can also be used for gameplay purposes. In many platformer games, the player will be injured if she touches an enemy with her left, right, or top hitboxes, but she will defeat the enemy if she touches it with her bottom hitbox (i.e. her feet).

Also today, I made several improvements under the hood related to coordinate spaces. The biggest improvement is that I established a distinction between “worldspace” — the coordinate space in which the gameplay occurs — and “screenspace” — the pixels on the screen. (There is also “gridspace”, the rows and columns of the tile grid. One unit in gridspace equals 21 pixels in screenspace.)

Before, worldspace and screenspace were the same: one pixel on the screen was the same as one unit in the game world. In order to avoid choppy, imprecise movement, I implemented my own bounding box type that used floating point numbers, and I used floating point numbers for the position, velocity, and acceleration of entities.

But, my bounding box type was essentially the same as SDL’s rect type, except that my type used floats and SDL’s type strictly uses integers. I found myself duplicating a lot of the functionality of rects, as well as procedures for converting from one type to the other. I decided that it would be better to just use SDL’s rect and point types directly. This also has benefit of allowing me to easily use SDL’s rect and point intersection functions.

In order to work around the fact that SDL’s rects and points use integers, I decided to define worldspace as being 1000 times the scale of screenspace. In other words, one pixel on the screen is equal to 1000 units in the game world. That means I get milli-pixel precision for movement and collision detection, while be able to use SDL’s functions, and have better performance because integer math is faster than floating point math.

As a future optimization, I might change the scale to 1024, so that I can use bit-shifting to convert between worldspace and screenspace. But for now, having a round 1000 makes it easier for me to interpret worldspace coordinates in my head while debugging.

I wrote a bunch of procedures for working with SDL rects and points. These are generally useful, so I put them in a shared directory so that I can use them in future example games. I am thinking about maybe adding some of them to chicken-sdl2. The fixnum procedures could be implemented in C for efficiency.

Finally, I have decided to simplify the game concept, in order to save time. Physics and collision detection have already used up three days, and probably the next day or two as well. It would take even longer if I tried to implement slopes, ladders, and water. So, I have decided to postpone those elements of the game until after the jam. Instead, I’m only going to have solid rectangular platforms that you can jump around on. Rectangular platforms will make collision detection and resolution simpler.

Tomorrow I hope to finish up collision detection and resolution for entities and tiles. I probably will not have player-to-player collision detection for this jam, but will add it later, after the jam.

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.