Category Archives: gamedev

Guile-2D is now named "Sly"

Guile-2D the a working title for my game engine written in Guile
Scheme. The name has become very limiting since I realized that it
wouldn’t be much extra work to support 3D graphics. After much
indecision, I’ve finally decided on an official name: Sly. I think
it’s a great name. It’s short, easy to type, and slyness is one of
the definitions of “guile”.

In other news:

  • Sly has a new contributor!
    Jordan Russel has written a
    new module
    that provides joystick input support.

  • I have written a
    module for describing animations.

  • I have been slowly working on a scene graph implementation that
    plays well with the functional reactive programming API.

  • As mentioned above, 3D graphics support is on the way! So far, I
    have implemented a perspective projection matrix, a “look at”
    matrix, and a cube primitive.

3D Scene Graph

Check out the Sly source code repository on
Gitorious!

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

Live Asset Reloading with guile-2d

Guile-2d provides a dynamic environment in which a developer can build
a game incrementally as it runs via the Guile REPL. It’s nice to be
able to hot-swap code and have the running game reflect the changes
made, but what about the game data files? If an image file or other
game asset is modified, it would be nice if the game engine took
notice and reloaded it automatically. This is what guile-2d’s live
asset reloading feature does.

The new (2d live-reload) module provides the live-reload
procedure. live-reload takes a procedure like load-texture
and returns a new procedure that adds the live reload magic. The new
procedure returns assets wrapped in a signal, a time-varying value. A
coroutine is started that periodically checks if the asset file has
been modified, and if so, reloads the asset and propagates it via the
signal. Game objects that depend on the asset will be regenerated
immediately.

Here’s some example code:

(define load-texture/live
  (live-reload load-texture))

(define-signal texture
  (load-texture/live "images/p1_front.png"))

(define-signal sprite
  (signal-map
   (lambda (texture)
     (make-sprite texture
                  #:position (vector2 320 240)))
   texture))

load-texture/live loads textures and reloads them when they change
on disk. Every time the texture is reloaded, the sprite is
regenerated using the new texture.

Here’s a screencast to see live reloading in action:

Guile-2d is ever-so-slowly approaching a 0.2 release. Stay tuned!

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

Functional Reactive Programming in Scheme with guile-2d

Last month, the GNU Guile project celebrated the 3rd anniversary of
its 2.0 release with a hacker potluck. Guilers were encouraged to
bring a tasty hack to the mailing list to share with everyone. My
dish was a simple functional reactive programming library.

Functional reactive programming (FRP) provides a way to describe
time-varying values and their relationships using a functional and
declarative programming style. To understand what this means, let’s
investigate a typical variable definition in Scheme. The expression
(define c (+ a b)) defines the variable c to be the sum of
variables a and b at the time of evaluation. If a or
b is assigned a new value, c remains the same. However, for
applications that deal with state that transforms over time, it would
be convenient if we could define c to react to changes in a
and b by recomputing the sum. Contrast this approach with the
more traditional style of modeling dynamic state via events and
callbacks. A lot of programmers, myself included, have written code
with so many callbacks that the resulting program is unmaintainable
spaghetti code. Callback hell is real, but if you accept FRP into
your heart then you will be saved!

By now you’re probably wondering: "What the hell does all this mean?"
So, here’s a real-world example of guile-2d’s FRP API:

(define-signal position
  (signal-fold v+ (vector2 320 240)
               (signal-map (lambda (v)
                             (vscale v 4))
                           (signal-sample game-agenda 1 key-arrows))))

In guile-2d, time-varying values are called "signals". The above
signal describes a relationship between the arrow keys on the keyboard
and the position of the player. signal-sample is used to trigger
a signal update upon every game tick that provides the current state
of the arrow keys. key-arrows is a vector2 that maps to the
current state of the arrow keys, allowing for 8 direction movement.
This vector2 is then scaled 4x to make the player move faster.
Finally, the scaled vector is added to the previous player position
via signal-fold. The player’s position is at (320, 240)
initially. As you can see, there are no callbacks and explicit
mutation needed. Those details have been abstracted away, freeing the
programmer to focus on more important things.

I think it’s helpful to see FRP in action to really appreciate the
magic. So, check out this screencast!

To see all of the juicy implementation details, check out the git
repository
. Thanks for following along!

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

Guile-2D 0.1 Release

To celebrate the GNU Project’s 30th anniversary, I have decided to
make the very first release of my 2D game development framework for
GNU Guile. GNU Guile is a Scheme implementation, and has the honor
of being the official extension language of the GNU project. Guile-2D
is a layer above SDL, OpenGL, FreeImage, and FTGL that provides
abstractions for common 2D game programming requirements such as
sprites, tilesets, animations, scripting, and collision detection.

There is a lot of work to do in order to get Guile-2D up to snuff with
the game libraries for more popular languages like Python and Lua. I
am looking for contributors who share my vision of creating a fully
featured, easy to use game library in Scheme.

Guile-2D currently supports GNU/Linux distributions. I am looking for
help to get it running on OS X and Windows.

Please refer to the INSTALL.org, README.org, and texinfo files to
learn how to install Guile-2D, run example programs, and write your
own games.

Download the release tarball
Browse the source code on GitHub

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

guile-2d – A 2D Game Development Framework for GNU Guile

This is the very first devlog entry for my pet project, guile-2d. As
the title suggests, guile-2d is a 2D game development framework for
GNU Guile, a Scheme implementation that has the honor of being the
official extension language of the GNU project. Guile is a language
with a growing number of features, but it still lacks a large
assortment of libraries. I like to do 2D game programming, and I saw a
niche that needed to be filled. Python has Pygame, Lua has Love, but
there’s no fun and accessible game programming library for
Guile. Guile-2d is working to correct that.

The goal of Guile-2d is to create an easy to use 2D game programming
framework. Libraries like SDL give the programmer a rather low-level
set of tools that they can use to build a game, guile-2d will provide
high-level tools over low-level SDL and OpenGL for commonly used
elements of 2D games: tile maps, sprite animation, particle systems,
collision detection, vector math, A* pathfinding, etc. Such features
will allow a game developer to very quickly produce a working
prototype with guile-2d.

Guile-2d is a framework, which means that it has some opinion about
what the right way to do things is. The most apparent example of this
is the game loop. The game loop runs at 60 frames-per-second and uses
fixed timestep updates. Those that have read Fix Your Timestep will
know that this decision is a good thing.

Perhaps the most important feature of guile-2d is the ability to do
"live coding". When the game loop starts, a REPL
(read-eval-print-loop) server is started. Using the great Geiser
extension for Emacs to connect to the REPL server, one can modify
their game as it is running. This gives users the power to evaluate
some new code and see the changes reflected immediately in the game
window. No need to restart the game unless you crash it!

This has been a brief overview of some of the features and goals of
guile-2d. If this project interests you, you can check out the source
code on Github.

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.