Next: , Up: API Reference   [Contents][Index]


2.1 Kernel

At the very core of Chickadee, in the (chickadee game-loop) module, lies an event loop. This loop, or “kernel”, is responsible for ensuring that the game is updated at the desired interval, rendering the current state of the game world, and handling errors if they occur. The kernel implements what is known as a “fixed timestep” game loop, meaning that the game simulation will be advanced by a fixed interval of time and will never vary from frame to frame, unlike some other styles of game loops. The appropriately named run-game* and abort-game procedures are the entry and exit points to the Chickadee game loop kernel.

On its own, the kernel does not do very much at all. In order to actually respond to input events, update game state, or render output, the programmer must provide an engine. But don’t worry, you don’t have to start from scratch! Chickadee comes with a simple engine that uses SDL to create a graphical window and handle input devices, and OpenGL to handle rendering. This default engine is enough for most users to get started writing games quickly. More advanced users may want to write a custom engine that uses a different I/O system. Perhaps you are writing a text adventure or roguelike that reads from and writes to a terminal instead of a graphical window. The game loop kernel makes no assumptions.

Procedure: run-game [#:update] [#:render] [#:time] [#:error] [#:update-hz 60]

Start the game loop. This procedure will not return until abort-game is called.

The core game loop is generic and requires four additional procedures to operate:

Procedure: abort-game

Stop the currently running Chickadee game loop.

Since most users will want to write 2D/3D games with hardware accelerated graphics rendering, controlled via keyboard, mouse, or game controller, Chickadee comes with an easy to use engine just for this purpose in the (chickadee) module: run-game.

Procedure: run-game [#:window-title "Chickadee!"] [#:window-width 640] [#:window-height 480] [#:window-fullscreen? #f] [#:update-hz 60] [#:load] [#:update] [#:draw] [#:quit] [#:key-press] [#:key-release] [#:text-input] [#:mouse-press] [#:mouse-release] [#:mouse-move] [#:controller-add] [#:controller-remove] [#:controller-press] [#:controller-release] [#:controller-move] [#:error]

Run the Chickadee game loop using the SDL engine in OpenGL mode.

A new graphical window will be opened with window-width x window-height as its dimensions, window-title as its title, and in fullscreen mode if window-fullscreen? is #t.

2.1.1 Live Coding

One of the biggest appeals of any Lisp dialect is the ability to use the “read-eval-print loop” (REPL for short) to build programs iteratively and interactively while the program is running. However, programs that run in an event loop and respond to user input (such as a video game) require special care for this workflow to be pleasant. Chickadee provides no built-in support for live coding, but it’s fairly easy to hook up a special kind of REPL yourself.

First, create a cooperative REPL server (It’s important to use Guile’s cooperative REPL server instead of the standard REPL server in (system repl server) to avoid thread synchronization issues):

(use-modules (system repl coop-server))

(define repl (spawn-coop-repl-server))

Then, in the game loop’s update procedure, add this:

(poll-coop-repl-server repl)

To use the REPL, connect to it via port 37146. Telnet will do the trick, but using the Geiser extension for Emacs is by far the best way to develop at the REPL with Guile. Use M-x connect-to-guile to connect to the REPL server.

Happy hacking!


Next: , Up: API Reference   [Contents][Index]