Next: Math, Up: API Reference [Contents][Index]
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.
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:
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
.
#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
.
alpha
value. See the documentation for
run-game
for an explanation of this value.
backspace
. It’s called a virtual key because the
operating system may map a physical keyboard key to another key
entirely, such as how the author likes to bind the “caps lock” key
to mean “control”.
ctrl
, alt
, and shift
.
#t
if this is a repeated press of the same key.
left
, middle
, or right
.
a
b
x
y
back
guide
start
left-stick
right-stick
left-shoulder
right-shoulder
dpad-up
dpad-down
dpad-left
dpad-right
left-x
left-y
right-x
right-y
trigger-left
trigger-right
The default behavior is to re-throw the error.
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: Math, Up: API Reference [Contents][Index]