Not as much progress today, since I had to work. But I did managed to implement broad phase collision detection (BPCD) between entities and tiles. BPCD is a quick first pass to narrow down the number of possible collisions that need to be tested more carefully. In this case, I'm looking for tiles that are near enough to an entity that there might possibly be a collision.
Full-featured physics engines often use spatial hashing for BPCD, but since tiles are laid out in a fixed grid, I can find nearby tiles by converting the entity's bounding box from worldspace coordinates (pixels) into tilespace coordinates (row/column).
Continue reading “Lisp Game Jam Log #5”
Today I started on the physics engine for my game. I have implemented the
Continue reading “Lisp Game Jam Log #4”
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.
I did not get quite as far on my game today as I hoped, due to distractions and other activities taking up time. But, I did write the level loader. You might notice that the level in the first screenshot here is the simple level from my last post.
Continue reading “Lisp Game Jam Log #3”
I am making progress on my game jam entry. Last night I was able to make the code to load a spritesheet from Kenney Game Assets, using spritesheet code I previously wrote for my eggsweeper example game. To test that the sprites were defined correctly, I arranged a simple scene, shown here in the screenshot.
Continue reading “Lisp Game Jam Log #2”
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.)
Continue reading “Lisp Game Jam Log #1”
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:
- Create a game for the game jam!
- Release chicken-sdl2 0.2 (the main new feature is 2D accelerated rendering).
- Create bindings for SDL_mixer, and possibly SDL_gfx.
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.
What's been going on with Cloje lately? Here's the short version:
Continue reading “Cloje Status Update (Taking Time Off)”
- I tried to add immutable types to Cloje. That turned out to be a bad decision at this stage of the project. So I'm backing off of that.
- I'm taking a month off from Cloje to recharge and reflect.
While preparing the Cloje 0.2 release last week, I came across something I had written, part of the goals for Cloje:
Importing all of Cloje will allow you to write code in a language very similar to Clojure. Or if you prefer, you will be able to pick and choose which pieces of Cloje to import, so that you are still mostly writing code in Scheme/Lisp, but with some added features from Clojure.
I had written that over a month ago, long before I had explored host interop issues. Reading it again during the release preparations made me wonder if I had neglected this use case when considering the host interop API design.
Continue reading “Cloje types vs host types, revisited”
Yesterday I tagged version 0.2 of Cloje. If you want to play around with it, you can clone the repository. Installation and usage instructions are available in the README.
In terms of features, the biggest changes in Cloje 0.2.0 are the addition of hash sets (an unordered collection of distinct elements), and several set operations based on the clojure.set standard library. Please read the release notes for the full list of changes in Cloje 0.2.0.
Also noteworthy is that the goal of Cloje has changed since 0.1. For reasons described in the Cloje 0.1 Post-Mortem, Cloje will no longer attempt to faithfully emulate Clojure. Instead, the new goal is to bring the best aspects of Clojure to Scheme/Lisp. The first effects of this new direction can be seen in the new set operations, whose behavior is more predictable and consistent than clojure.set when given non-set collections. The old goal would have required me to laboriously recreate Clojure's quirks and bugs, rather than address and fix them.
Tentative plans for 0.3 are to create placeholder types (vectors, maps, etc.) and an API to convert between Cloje types and host types. This will set the stage for adding Clojure-style immutable persistent data structures in the future. The placeholder types will be immutable, but not (yet) have the structural sharing of Clojure's types.
Besides writing code, I will also be dedicating a significant portion of my project time to establishing policies, project documentation (how to start contributing, etc.), and outreach to help get more people involved in the project, especially people from underrepresented groups.