John Croisant

Oh, how time flies! Yesterday marked the tenth anniversary of this blog.
To commemorate, I am relaunching my site under a new domain.
Also in the spirit of renewal, I’ll be doing some spring cleaning,
wrapping up old projects so I can focus on things
that are more relevant to me now.

This is the first in a series of posts where I attempt to understand and explain how UI layout constraints (such as Apple's Auto Layout) work and are implemented. Along the way, we will learn about a field of mathematics known as "linear programming".

In this first post, I will introduce the concepts of UI layout constraints and linear programming. I will also convert a UI layout constraint example into a system of linear equations, and graph the system visually. In future posts, I will explain the simplex method, the Cassowary algorithm, and how to implement the Cassowary algorithm as a computer program.

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.

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.

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.

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.

Yesterday I got pretty far along with implementing user input. I spent more time on it than I should, but I'm fairly happy with the results. The system is much more complex than other demos, in order to be flexible enough to allow the user to customize their controls.

I made a lot of progress today. I finished narrow phase collision detection (NPCD) between entities and tiles, added support for partial-sized tiles, added collision resolution and friction for players (and ice tiles!), decoupled the physics simulation from the render framerate, and added support for a live REPL so I can type in commands to modify the game while it is running!

I already wrote about NPCD in my last post, so I won't say much more here, except that I finished implementing it. In the process, I added support for partial-sized tiles. Certain tiles only fill part of a grid cell. For example, the floating grass tile that the yellow character is standing on only fills the top half of its cell, and the thin wood tile that the pink alien is standing on only fills the bottom third of its cell. The shape of each tile is defined in its properties as a symbol, e.g. 'top-half or 'bottom-third, and the tile's hitbox is generated based on the symbol.

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.