Guile Game Library

Guile Game Library

[David Thompson]

Hello all,

In my free time I like to tinker with game development, and I also like 
to tinker with Guile.
I come from a Python background where I used such libraries as Pyglet 
and Pygame.
These libraries were easy to use and had all the conveniences for making 
2D games (Pyglet sports a full GL binding for doing more advanced stuff 
as well).
I haven't found a similar library for Guile. Is there one that I haven't 
discovered?

If there isn't, one should be made. Pygame is a fun treat for new Python 
programmers, and I think a similar library for Guile would be even more 
fun. :)
In the past I've tried to wrap the Allegro 5 library using the Guile C 
API, and also with the FFI. My experience doing so lead me to the 
conclusion that a game library developed completely in Guile, not just a 
mere wrapper, would ultimately be much more satisfying.

Now, how would this be achieved? I looked briefly at the source code of 
Pygame and Pyglet and learned the following:
Pygame uses the Python C API to wrap up a bunch of SDL calls. Since 
Pygame uses SDL, the graphics functions use a software renderer which 
isn't optimal.
Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet 
sports OpenGL, X11, and FreeType bindings to name a few. I personally 
prefer this development model over Pygame's.

What Guile libraries already exist that can provide needed 
functionality? (Windows, Graphics, Sound, Keyboard/mouse/joystick input, 
Fonts, Physics, etc.)

What libraries would best suit this purpose? Figl (wingo's GL binding) 
is an obvious choice, as well as a Freetype binding (that I'm not sure 
exists). But what about the other important pieces such as sound and input?

Thanks, Guilers!

- Dave

Re: Guile Game Library

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

在 2013-5-29 AM8:31，"David Thompson" <dthompson2@worcester.edu>写道：
>
> Hello all,
>
> In my free time I like to tinker with game development, and I also like
to tinker with Guile.
> I come from a Python background where I used such libraries as Pyglet and
Pygame.
> These libraries were easy to use and had all the conveniences for making
2D games (Pyglet sports a full GL binding for doing more advanced stuff as
well).
> I haven't found a similar library for Guile. Is there one that I haven't
discovered?
>
> If there isn't, one should be made. Pygame is a fun treat for new Python
programmers, and I think a similar library for Guile would be even more
fun. :)
> In the past I've tried to wrap the Allegro 5 library using the Guile C
API, and also with the FFI. My experience doing so lead me to the
conclusion that a game library developed completely in Guile, not just a
mere wrapper, would ultimately be much more satisfying.
>
> Now, how would this be achieved? I looked briefly at the source code of
Pygame and Pyglet and learned the following:
> Pygame uses the Python C API to wrap up a bunch of SDL calls. Since
Pygame uses SDL, the graphics functions use a software renderer which isn't
optimal.
> Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet
sports OpenGL, X11, and FreeType bindings to name a few. I personally
prefer this development model over Pygame's.
>
> What Guile libraries already exist that can provide needed functionality?
(Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics,
etc.)
>
> What libraries would best suit this purpose? Figl (wingo's GL binding) is
an obvious choice, as well as a Freetype binding (that I'm not sure
exists). But what about the other important pieces such as sound and input?
>

I'm glad that someone is interested on it :)
And maybe you are looking for TTN's guile-SDL? It works anyway.
But I'm not sure that Freetype binding exists.

> Thanks, Guilers!
>
> - Dave
>

[-- Attachment #2: Type: text/html, Size: 2349 bytes --]

Re: Guile Game Library

[David Thompson]

On 05/28/2013 08:41 PM, Nala Ginrut wrote:
>
> I'm glad that someone is interested on it :)
> And maybe you are looking for TTN's guile-SDL? It works anyway.
> But I'm not sure that Freetype binding exists.
>
Guile-SDL has some issues of its own (I got frustrated trying to install 
and use it), and SDL in general (at least until 2.0 is stable) suffers 
from using software rendering instead of OpenGL.

Pygame, although it wraps up many SDL features, provides a very Pythonic 
API and includes other helpful things written in pure Python (the Rect 
class comes to mind) and is thus not just an ordinary binding.

Re: Guile Game Library

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

() David Thompson <dthompson2@worcester.edu>
() Tue, 28 May 2013 20:45:37 -0400

   Guile-SDL has some issues of its own [...]

Please, could you describe these issues (in some detail)?

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Guile Game Library

[David Thompson]

On 05/29/2013 04:09 AM, Thien-Thi Nguyen wrote:
> () David Thompson <dthompson2@worcester.edu>
> () Tue, 28 May 2013 20:45:37 -0400
>
>     Guile-SDL has some issues of its own [...]
>
> Please, could you describe these issues (in some detail)?
>
Sure, the first problem that prevented me from building was that 
guile-sdl depends on something called "snuggle" that there isn't much 
information about.
Someone on #guile then said that guile-sdl was pretty unstable so I lost 
interest in building.
I can try again. :)

SDL alone doesn't meet my requirements since all of SDL's handy drawing 
functions use a software renderer.

Figl has a GLUT binding that will take care of windowing and 
keyboard/mouse input, further minimizing the usefulness of SDL.

Re: Guile Game Library

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

() David Thompson <dthompson2@worcester.edu>
() Wed, 29 May 2013 06:52:29 -0400

   Sure, the first problem that prevented me from building was that
   guile-sdl depends on something called "snuggle" that there isn't
   much information about.

It sounds like you were trying to bootstrap from a repo checkout.
Did you try a released (versioned) tarball?

   Someone on #guile then said that guile-sdl was pretty unstable so I
   lost interest in building.  I can try again. :)

Who knows, maybe since you last tried things have improved.

   SDL alone doesn't meet my requirements since all of SDL's handy
   drawing functions use a software renderer.

   Figl has a GLUT binding that will take care of windowing and
   keyboard/mouse input, further minimizing the usefulness of SDL.

Well, if your requirements drift into Guile-SDL's domain and you run
into specific problems w/ a released tarball, i'd appreciate hearing
about them.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Guile Game Library

[Thompson, David]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

I'll give a released tarball a shot. Thanks.


On Wed, May 29, 2013 at 2:59 PM, Thien-Thi Nguyen <ttn@gnu.org> wrote:

> () David Thompson <dthompson2@worcester.edu>
> () Wed, 29 May 2013 06:52:29 -0400
>
>    Sure, the first problem that prevented me from building was that
>    guile-sdl depends on something called "snuggle" that there isn't
>    much information about.
>
> It sounds like you were trying to bootstrap from a repo checkout.
> Did you try a released (versioned) tarball?
>
>    Someone on #guile then said that guile-sdl was pretty unstable so I
>    lost interest in building.  I can try again. :)
>
> Who knows, maybe since you last tried things have improved.
>
>    SDL alone doesn't meet my requirements since all of SDL's handy
>    drawing functions use a software renderer.
>
>    Figl has a GLUT binding that will take care of windowing and
>    keyboard/mouse input, further minimizing the usefulness of SDL.
>
> Well, if your requirements drift into Guile-SDL's domain and you run
> into specific problems w/ a released tarball, i'd appreciate hearing
> about them.
>
> --
> Thien-Thi Nguyen
> GPG key: 4C807502
>

[-- Attachment #2: Type: text/html, Size: 1725 bytes --]

Re: Guile Game Library

[Javier Sancho]

At http://lists.gnu.org/archive/html/guile-user/2013-05/msg00025.html
you can read an interesting discussion about games development on
Guile.

In my opinion, although it would be nice to have something similar to
pygame or pyglet, that's not exactly the way. It would be better a
more functional style library or engine, as Haskell Yampas, or an
entity oriented system as Unity3D.

For me, binding i/o features is not an issue. Currently, using Guile
FFI allow us to quickly achieve this task. And we have Guile-SDL and
Figl. It's more important to design a good scalable way for making
games, something that you could use to make prototyping and to make a
great professional game, too.

Last days, I read "What is an entity system framework for game
development?" [1], "Entity Systems are the future of MMOG development"
[2] and "Purely Functional Retrogames" [3] and I am directing Gacela,
my experimental games engine, to a similar style of doing things,
using components for the entities and working with subsystems that
could run in the same thread or in various threads. You can find very
interesting articles at Haskell Game Development page [4].

Cheers.

[1] http://www.richardlord.net/blog/what-is-an-entity-framework
[2] http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
[3] http://prog21.dadgum.com/23.html
[4] http://www.haskell.org/haskellwiki/Game_Development

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: Guile Game Library

[David Thompson]

On 05/29/2013 02:38 AM, Javier Sancho wrote:
> At http://lists.gnu.org/archive/html/guile-user/2013-05/msg00025.html
> you can read an interesting discussion about games development on
> Guile.
>
> In my opinion, although it would be nice to have something similar to
> pygame or pyglet, that's not exactly the way. It would be better a
> more functional style library or engine, as Haskell Yampas, or an
> entity oriented system as Unity3D.
>
> For me, binding i/o features is not an issue. Currently, using Guile
> FFI allow us to quickly achieve this task. And we have Guile-SDL and
> Figl. It's more important to design a good scalable way for making
> games, something that you could use to make prototyping and to make a
> great professional game, too.
>
> Last days, I read "What is an entity system framework for game
> development?" [1], "Entity Systems are the future of MMOG development"
> [2] and "Purely Functional Retrogames" [3] and I am directing Gacela,
> my experimental games engine, to a similar style of doing things,
> using components for the entities and working with subsystems that
> could run in the same thread or in various threads. You can find very
> interesting articles at Haskell Game Development page [4].
>
> Cheers.
>
> [1] http://www.richardlord.net/blog/what-is-an-entity-framework
> [2] http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
> [3] http://prog21.dadgum.com/23.html
> [4] http://www.haskell.org/haskellwiki/Game_Development
>
> --
> Javier Sancho Fernández - http://www.jsancho.org/
> Associate Member of the Free Software Foundation - http://www.fsf.org/
> Contra el DRM - http://www.defectivebydesign.org/what_is_drm
Maybe I have an unpopular opinion here, but I've done some reading and 
experimenting with Entity systems and I remain unconvinced of their 
usefulness.

Is the source for Gacela available?

Re: Guile Game Library

[Javier Sancho]

David Thompson wrote:
> Maybe I have an unpopular opinion here, but I've done some reading and
> experimenting with Entity systems and I remain unconvinced of their
> usefulness.

In my view, playing with entities gives two ways for doing things in a
game. Game designers work with "objects" that have components that
have properties, i.e., it's possible to create a ship with a position
and a velocity. And game programmers work with data (or functions)
which are passed to a system (function) that returns data (or
functions), so these systems can be treated separately, can be running
in another processor, etc.

But it's my opinion. What problems have you encountered using entity systems?

> Is the source for Gacela available?

http://hg.savannah.nongnu.org/hgweb/gacela/

But it's the previous version with an object oriented vision and a
little unstable. I am designing a new approach based on entity systems
and I hope I start writing code soon.

Cheers.

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: Guile Game Library

[David Thompson]

On 05/30/2013 06:07 AM, Javier Sancho wrote:
> In my view, playing with entities gives two ways for doing things in a 
> game. Game designers work with "objects" that have components that 
> have properties, i.e., it's possible to create a ship with a position 
> and a velocity. And game programmers work with data (or functions) 
> which are passed to a system (function) that returns data (or 
> functions), so these systems can be treated separately, can be running 
> in another processor, etc. But it's my opinion. What problems have you 
> encountered using entity systems?

I haven't tried implementing an entity-component system in Scheme, but 
in the past I've tried to grok writings on the subject and wrote an 
implementation in C++ and later in Python. The Python version worked 
much better than the C++ version, since Python is more dynamic. I like 
components in theory as it provides a good separation of concerns, but 
in practice it always ended up being too complex to work with. The 
dependencies between components and the message passing were hard to 
deal with nicely. In the end I would just fall back to a much simpler 
model to represent game objects.

> http://hg.savannah.nongnu.org/hgweb/gacela/
>
> But it's the previous version with an object oriented vision and a
> little unstable. I am designing a new approach based on entity systems
> and I hope I start writing code soon.

I'm interested to see how you implement your entity-component system. 
You seem to have a better idea of how to do it than I do.

>
> Cheers.
>
> --
> Javier Sancho Fernández - http://www.jsancho.org/
> Associate Member of the Free Software Foundation - http://www.fsf.org/
> Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: Guile Game Library

[Javier Sancho]

David Thompson wrote:
> I'm interested to see how you implement your entity-component system. You
> seem to have a better idea of how to do it than I do.

Ouoh, we will see. For the moment, I only talk a lot, smoke everywhere :-)


--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: Guile Game Library

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 4401 bytes --]

2013/5/29 David Thompson <dthompson2@worcester.edu>

> Hello all,
>
> In my free time I like to tinker with game development, and I also like to
> tinker with Guile.
> I come from a Python background where I used such libraries as Pyglet and
> Pygame.
> These libraries were easy to use and had all the conveniences for making
> 2D games (Pyglet sports a full GL binding for doing more advanced stuff as
> well).
> I haven't found a similar library for Guile. Is there one that I haven't
> discovered?
>
>
Actually, I've been trying to develop a game in guile, and on my way I
coined the SLAYER environment, which can be obtained via mercurial:
$ hg clone https://bitbucket.org/panicz/slayer
$ cd slayer

Provided that you have all the packages listed in the DEPENDENCIES file, it
should get built using
$ make

However, you may wish to switch to "autotools" branch, which contains some
more recent changes and more informative demos:
$ hg up autotools
$ ./configure
and
$ make
(I wouldn't recommend to 'make install' yet though, as there are still some
issues that need to be resolved)

If you manage to go through this somewhat cumbersome build process, you can
try out the demos, by entering the demos directory and typing
$ ./slayer -e3d -islayer.scm
and
$ ./slayer -ipong.scm

There's also a possibility to build a library that wraps the Open Dynamics
Engine, and there's a corresponding demo which shows its capabilities (like
everything in SLAYER, this isn't just a simple wrapper on the C functions,
but rather an interface which simplifies the development)

If there isn't, one should be made. Pygame is a fun treat for new Python
> programmers, and I think a similar library for Guile would be even more
> fun. :)
> In the past I've tried to wrap the Allegro 5 library using the Guile C
> API, and also with the FFI. My experience doing so lead me to the
> conclusion that a game library developed completely in Guile, not just a
> mere wrapper, would ultimately be much more satisfying.
>
>
My vision of SLAYER is to make a self-contained development environment, so
that it could have its own editors (for code, but also for 3d mesh, sound
waves, rigs or video streams) -- so I believe that it could evolve towards
something like emacs, but focused on multimedia

Now, how would this be achieved? I looked briefly at the source code of
> Pygame and Pyglet and learned the following:
> Pygame uses the Python C API to wrap up a bunch of SDL calls. Since Pygame
> uses SDL, the graphics functions use a software renderer which isn't
> optimal.
> Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet
> sports OpenGL, X11, and FreeType bindings to name a few. I personally
> prefer this development model over Pygame's.
>
>
I have no experience with any of those, so I cannot compare. SLAYER is
based entirely on SDL and OpenGL (which is optional). It also wraps
SDL_image, SDL_mixer for audio and SDL_ttf for FreeType fonts. Rendering
can be done using either plain SDL or via OpenGL (which currently must be
enabled using the "-e3d" command line option), and in the latter case no
SDL routines are used for rendering.

What Guile libraries already exist that can provide needed functionality?
> (Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics,
> etc.)
>
What libraries would best suit this purpose? Figl (wingo's GL binding) is
> an obvious choice, as well as a Freetype binding (that I'm not sure
> exists). But what about the other important pieces such as sound and input?
>
>
Except SLAYER, guile-SDL provides support for all of the features you
mentioned (except Physics). Its advantage is a much better documentation
(SLAYER currently offers none), easier build process and a larger set of
demos.
Also, SLAYER has no joystick support (it could be added easily, but I
wouldn't have any option to test it).
However, the advantage of SLAYER is that it's something more than just a
wrapper: it is an abstraction layer, which could be implemented in many
other environments. It offers an event-driven input model, so the
programmer doesn't have to write his own input loop. Furthermore, it
provides a GOOPS-based framework for widgets.

I recommend you to look at the source of the demos to see how it works, and
if you have any questions, I'm eager to help. Maybe the overall process
could help come up with some documentation.

Best regards,
M.

[-- Attachment #2: Type: text/html, Size: 6817 bytes --]

Re: Guile Game Library

[David Thompson]

I'll give SLAYER a try before judging it, but my initial impression is 
that it's not a good fit for me. Our goals seem to be different, and it 
seems that you have your sights aimed much higher. Emacs is my 
development environment and I'm not looking for a specialized 
development environment to build games in using SLAYER or any other library.

I do really like that SLAYER can operate with software rendering OR 
OpenGL rendering. That is quite the nice feature.

Perhaps I should explain my position more. My focus is on 2D game 
development (but that's not to say that I want a library that is limited 
to only 2D), which means I want a library with features like sprites, 
sprite batching, tiling, animation, a 2D scene graph, event scripting, etc.

A combination of Guile-SDL and Figl could fit the bill for the base to 
build off of.

Thoughts?

Re: Guile Game Library

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

2013/5/29 David Thompson <dthompson2@worcester.edu>

> I'll give SLAYER a try before judging it, but my initial impression is
> that it's not a good fit for me. Our goals seem to be different, and it
> seems that you have your sights aimed much higher. Emacs is my development
> environment and I'm not looking for a specialized development environment
> to build games in using SLAYER or any other library.
>
>
Well, currently I also use Emacs. However, I see that in the process of
game development it is very important to be able to make editors for
certain features.
SLAYER is a very general (or generic) environment, and the idea is just to
build various libraries around the core, which is responsible for input
handling and audiovisuals.
I hope that one day I manage to transpose the idea of REPL onto the world
of GUI somehow, but it's just a distant vision.
However, having an in-game code editor is just something that I need for
the game that I'm developing.

I do really like that SLAYER can operate with software rendering OR OpenGL
> rendering. That is quite the nice feature.
>
> Perhaps I should explain my position more. My focus is on 2D game
> development (but that's not to say that I want a library that is limited to
> only 2D), which means I want a library with features like sprites, sprite
> batching, tiling, animation, a 2D scene graph, event scripting, etc.
>

I know of no library for Guile that would provide those features out of the
box. I believe it should be fairly easy to provide animation framework for
SLAYER. When it comes to some other features, honestly, I haven't
considered the code performance issues yet (I've rather been concerned with
the performance of the development process), so I'm unfamiliar with
features like sprite batching nor efficient tiling. The sprites themselves
are supported, whether they are loaded from external files, or generated as
a two-dimensional array (there are array->image and image->array functions
that allow for an easy conversion)

I follow David Knuth's advice and act as if "premature optimization was the
root of all evil" -- I believe it is more important to have a working game
ASAP and optimize only when I know which optimizations are needed than to
worry a priori.

Best regards,
M.

[-- Attachment #2: Type: text/html, Size: 3310 bytes --]