Lisp Game Jam Log #4
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.