[ANN] gzochi project development release 0.5

[ANN] gzochi project development release 0.5

[Julian Graham]

Hi everyone,

I'm pleased to announce the fifth development release of the gzochi
game development framework.

The project description, from Savannah: gzochi (/zoʊ-tʃiː/) is a
framework for developing massively multiplayer online games. A server
container provides services to deployed games, which are written in
Guile Scheme, that abstract and simplify some of the most challenging
and error-prone aspects of online game development: Concurrency, data
persistence, and network communications. A very thin client library
can be embedded to provide connectivity for client applications
written in any language. gzochi can be viewed as an application server
(plus clients) for Guile applications that have special kinds of
workloads -- quick, CPU-bound tasks that require transactional
guarantees around sending messages and accessing data.

This is primarily a bug fix release, focused on improving the
stability and correctness of durable task scheduling and transactional
access to data. Additionally, it includes:

* A new scalable data structure in the Scheme API, based on SRFI-44
sequences: gzochi:managed-sequence

* Reporting of average transaction duration via the server's embedded
administrative web console

* Performance improvements to both the server and reference client
implementations

* ...and more! See the NEWS files in the distribution for details

This is a development release; the framework is largely
feature-complete but likely not bug-free. Nonetheless, there's
extensive server and client documentation, and the distribution
includes two example games with heavily-annotated source code. For
more information, visit http://www.nongnu.org/gzochi/ or check out the
project page on Savannah, at
http://savannah.nongnu.org/projects/gzochi/ -- you can pick up the
release
from the downloads section.


Regards,
Julian

Re: [ANN] gzochi project development release 0.5

[Thompson, David]

On Wed, Jan 15, 2014 at 1:40 PM, Julian Graham <joolean@gmail.com> wrote:
> Hi everyone,

Hello, Julian.

>
> I'm pleased to announce the fifth development release of the gzochi
> game development framework.
>
> The project description, from Savannah: gzochi (/zoʊ-tʃiː/) is a
> framework for developing massively multiplayer online games. A server
> container provides services to deployed games, which are written in
> Guile Scheme, that abstract and simplify some of the most challenging
> and error-prone aspects of online game development: Concurrency, data
> persistence, and network communications. A very thin client library
> can be embedded to provide connectivity for client applications
> written in any language. gzochi can be viewed as an application server
> (plus clients) for Guile applications that have special kinds of
> workloads -- quick, CPU-bound tasks that require transactional
> guarantees around sending messages and accessing data.

I am working on a 2D game development library
(https://gitorious.org/guile-2d/guile-2d/) that is still in its early
stages. I'm curious about how much our efforts overlap and if they
could be used together easily. My library is concerned with graphics,
audio, and user input and yours appears to be a client/server
framework, so I think that with our powers combined we can make 2D
multiplayer games with Guile. :)

I think it would be really useful if your website showed some example
code snippets to make it clear as to what problems your software is
solving and how it solves them. It's not immediately clear to me how I
would get started using gzochi.

That said, it's an exciting project. Congrats on the release!

- Dave Thompson

Re: [ANN] gzochi project development release 0.5

[Julian Graham]

Hi Dave,

On Wed, Jan 15, 2014 at 1:59 PM, Thompson, David
<dthompson2@worcester.edu> wrote:
> I am working on a 2D game development library
> (https://gitorious.org/guile-2d/guile-2d/) that is still in its early
> stages. I'm curious about how much our efforts overlap and if they
> could be used together easily. My library is concerned with graphics,
> audio, and user input and yours appears to be a client/server
> framework, so I think that with our powers combined we can make 2D
> multiplayer games with Guile. :)

Cool!


> I think it would be really useful if your website showed some example
> code snippets to make it clear as to what problems your software is
> solving and how it solves them. It's not immediately clear to me how I
> would get started using gzochi.

The gzochid manual has a kind of rationale section which describes the
problem space that gzochi addresses:
http://www.nongnu.org/gzochi/gzochid.html#Conceptual-overview. There's
also a trivial application you can look at to get a sense of what
gzochi application code looks like:
http://www.nongnu.org/gzochi/gzochid.html#An-example-application

For a deeper dive into non-trivial application development, you'll
need to download the distribution and take a look at the two example
games, Mazewar and AberMUD, which are both "remixes" of classic
network multiplier games, and which have fairly exhaustive
documentation and inline comments.

I'm going to be polishing up the web site soon, and I'll try to bring
some of that stuff closer to the surface. Let me know if you've got
additional thoughts on how to make the site or documentation more
useful / accessible.


Regards,
Julian

Re: [ANN] gzochi project development release 0.5

[Thompson, David]

On Wed, Jan 15, 2014 at 2:09 PM, Julian Graham <joolean@gmail.com> wrote:
> Hi Dave,
>
> The gzochid manual has a kind of rationale section which describes the
> problem space that gzochi addresses:
> http://www.nongnu.org/gzochi/gzochid.html#Conceptual-overview. There's
> also a trivial application you can look at to get a sense of what
> gzochi application code looks like:
> http://www.nongnu.org/gzochi/gzochid.html#An-example-application

Thanks for the links.

> For a deeper dive into non-trivial application development, you'll
> need to download the distribution and take a look at the two example
> games, Mazewar and AberMUD, which are both "remixes" of classic
> network multiplier games, and which have fairly exhaustive
> documentation and inline comments.

I perused the examples directory. Wasn't expecting so much C. ;)

> I'm going to be polishing up the web site soon, and I'll try to bring
> some of that stuff closer to the surface. Let me know if you've got
> additional thoughts on how to make the site or documentation more
> useful / accessible.

I think some code snippets with commentary staring you in the face on
the home page would go a long way.

- Dave

Re: [ANN] gzochi project development release 0.5

[Julian Graham]

> I perused the examples directory. Wasn't expecting so much C. ;)

Yeah, that'd be the clients – the server side of these applications is
all Scheme. This is going to sound crazy, but it hadn't occurred to me
to provide a reference client in Scheme. I'll be sure to add one in
the next release!

Re: [ANN] gzochi project development release 0.5

[Thompson, David]

On Wed, Jan 15, 2014 at 2:22 PM, Julian Graham <joolean@gmail.com> wrote:
> This is going to sound crazy, but it hadn't occurred to me
> to provide a reference client in Scheme. I'll be sure to add one in
> the next release!

That would be great!

Happy hacking and whatnot. :)

Re: [ANN] gzochi project development release 0.5

[Panicz Maciej Godek]

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

Hi guys!
Since I'm also an author of a(nother) multimedia framework
in guile+sdl/opengl called SLAYER, I thought that I might join
the conversation :)

Perhaps it would make sense to collaborate more and to somehow
integrate our efforts. It might seem difficult at first, because
I guess that everyone of us does his work in his spare time,
and our plans and visions might be vague, but it would be really
nice if we were able at least to formulate the intersections of our
goals.

Mine is to create games that would teach their players programming,
i.e. to show that some repeatable actions could be automated quite
easily and naturally with simple scripts, that could later on become
more complex.

I thought that it would be more motivating if a gameplay was set
up in a competetive environment, so that the players would easily
see that even simple programatic enhancements of their user
interface would give them an advantage over their opponents.

I came up with the idea of a 3d robot sword battle game, where
the players can come up with new moves for their avatars,
and even write scripts that would control their robots entirely.

For that reason, SLAYER is equipped with bindings to Open
Dynamics Engine, and also has a stub of a text editor widget
(which obiously allows to evaluate lisp expressions in a similar
way emacs+geiser does ;])

Some time ago, I have also been experimenting with a design
of a general network architecture, but I eventually dropped it,
believing that there were some more urgent things to be done.

Anyway, the goal is ambitious, and I think that for that reason
we have a lot in common. There are also some ideas that I
see in guile-2d and that I truly love and would love to steal,
but that's impossible, because it's LGPL :)

I also see that our approach differs in that I have been
using the GOOPS system extensively for the GUI design
(which has some advantages, despite its drawbacks, such
as decreased portability between other Scheme
implementations)

One thing that might seem dubious is my decision to keep
slayer a stand-alone application (rather than guile module).
It is not a deep decision and could be changed rather easily,
but as for now it has proven good at some points (namely,
it gave me a better control over the program behaviour while
I was creating a Windows port), and a pain-in-the-ass at
anothers (it's difficult to create slayer applications using the
emacs+geiser methodology).

Anyway, if any of you thinks that we could cooperate,
I'm really looking forward to it. I'd also like to hear about
your goals and ideas, if you're willing to share :)

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

Re: [ANN] gzochi project development release 0.5

[Thompson, David]

On Wed, Jan 15, 2014 at 2:56 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
> Hi guys!
> Since I'm also an author of a(nother) multimedia framework
> in guile+sdl/opengl called SLAYER, I thought that I might join
> the conversation :)
>
> Perhaps it would make sense to collaborate more and to somehow
> integrate our efforts. It might seem difficult at first, because
> I guess that everyone of us does his work in his spare time,
> and our plans and visions might be vague, but it would be really
> nice if we were able at least to formulate the intersections of our
> goals.

Yes, I agree.

> Mine is to create games that would teach their players programming,
> i.e. to show that some repeatable actions could be automated quite
> easily and naturally with simple scripts, that could later on become
> more complex.
>
> I thought that it would be more motivating if a gameplay was set
> up in a competetive environment, so that the players would easily
> see that even simple programatic enhancements of their user
> interface would give them an advantage over their opponents.
>
> I came up with the idea of a 3d robot sword battle game, where
> the players can come up with new moves for their avatars,
> and even write scripts that would control their robots entirely.
>
> For that reason, SLAYER is equipped with bindings to Open
> Dynamics Engine, and also has a stub of a text editor widget
> (which obiously allows to evaluate lisp expressions in a similar
> way emacs+geiser does ;])
>
> Some time ago, I have also been experimenting with a design
> of a general network architecture, but I eventually dropped it,
> believing that there were some more urgent things to be done.

You could perhaps use gzochi for this now.

> Anyway, the goal is ambitious, and I think that for that reason
> we have a lot in common. There are also some ideas that I
> see in guile-2d and that I truly love and would love to steal,
> but that's impossible, because it's LGPL :)

I guess there is a gap in my understanding of the compatibility
between the GPL and LGPL. I chose the LGPL for 2 reasons: It is the
same license as Guile and there are already a million game libraries
out there that are either proprietary or more liberally licensed so I
also opted for a more liberal license. I could surely grant exceptions
to let you use my code for SLAYER, if necessary.

> I also see that our approach differs in that I have been
> using the GOOPS system extensively for the GUI design
> (which has some advantages, despite its drawbacks, such
> as decreased portability between other Scheme
> implementations)

Ah, I have chosen to not depend on GOOPS in favor of plain old record types.

> One thing that might seem dubious is my decision to keep
> slayer a stand-alone application (rather than guile module).
> It is not a deep decision and could be changed rather easily,
> but as for now it has proven good at some points (namely,
> it gave me a better control over the program behaviour while
> I was creating a Windows port), and a pain-in-the-ass at
> anothers (it's difficult to create slayer applications using the
> emacs+geiser methodology).

Our differing choices is a good example of "embedding vs. extending".
You've probably already read this article
(https://twistedmatrix.com/users/glyph/rant/extendit.html) but it
explains exactly why I prefer to extend.

One of Guile-2d's main goals is to work really nicely with Emacs +
Geiser. I am working on a patch for the Guile 2.0.10 release that will
allow any Guile program that runs an event loop to integrate a REPL
server that doesn't have the multi-threading issues present with the
normal REPL server. So, if you are open to turning SLAYER into a
shared library, I hope that a free REPL server will sweeten the deal.
:)

> Anyway, if any of you thinks that we could cooperate,
> I'm really looking forward to it. I'd also like to hear about
> your goals and ideas, if you're willing to share :)

I would definitely like to cooperate. Perhaps there is a library or
two that we could extract from our projects for everyone to use.

My main goal is to apply the Emacs philosophy to game development. I
want guile-2d to be an easy way to create 2D games interactively using
the REPL with the ideal environment being Emacs + Geiser. Ideally,
guile-2d will remain pure Guile and use the CFFI to call out to other
libraries.

- Dave

Re: [ANN] gzochi project development release 0.5

[Panicz Maciej Godek]

Hi!

<2014/1/15 Thompson, David <dthompson2@worcester.edu>

> > For that reason, SLAYER is equipped with bindings to Open
> > Dynamics Engine, and also has a stub of a text editor widget
> > (which obiously allows to evaluate lisp expressions in a similar
> > way emacs+geiser does ;])
> >
> > Some time ago, I have also been experimenting with a design
> > of a general network architecture, but I eventually dropped it,
> > believing that there were some more urgent things to be done.
>
> You could perhaps use gzochi for this now.

I'd have to read a bit more about it, because although it sounds
really cool (and may turn out to suit my needs exactly), the
documentation is rather voluminous.
So if I manage to keep up with my ideas, I'll definitely dive into it :]

> > Anyway, the goal is ambitious, and I think that for that reason
> > we have a lot in common. There are also some ideas that I
> > see in guile-2d and that I truly love and would love to steal,
> > but that's impossible, because it's LGPL :)
>
> I guess there is a gap in my understanding of the compatibility
> between the GPL and LGPL. I chose the LGPL for 2 reasons: It is the
> same license as Guile and there are already a million game libraries
> out there that are either proprietary or more liberally licensed so I
> also opted for a more liberal license. I could surely grant exceptions
> to let you use my code for SLAYER, if necessary.

Well, I meant that it's impossible, because it's free software :)
I decided to equip SLAYER with GPL mainly because I wouldn't any
non-free modifications to appear, because however strange it may
sound, there seem to be many people who don't have a clue about the
idea of free software.

But anyway, I think that FSF favours GPL over LGPL, and that it is
possible to convert LGPL to GPL (which is more restrictive) and not
the other way around.

> > I also see that our approach differs in that I have been
> > using the GOOPS system extensively for the GUI design
> > (which has some advantages, despite its drawbacks, such
> > as decreased portability between other Scheme
> > implementations)
>
> Ah, I have chosen to not depend on GOOPS in favor of plain old record types.

I am curious what caused that decision. It seems reasonable, because
it allows to keep the source relatively portable. On the other hand,
GUI goes rather naturally with OOP, and although it's still an
experiment, and I'm lacking certain features that are present in some
more widespread OOP systems, it's certainly
comfortable to have that multi-method dispatch, as it allows to write
programs in a more flexible (and a little carefree) manner.

The nice thing about it is that it works a little bit like the natural
language, where the meaning of certain words depend on their context.

But I actually dislike a few aspects. First that I know of no good
method for creating hidden slots, i.e. such that their storage would
be accessible only via virtually allocated slots.

The second is that there is there is no way to specify a type for a
slot. I can only provide a comment, but it's not particularly
reliable.

It is also slightly annoying that I have to define a class before I
can refer to it, e.g. in a method definition. It causes the code to be
scattered around in the file.

> > One thing that might seem dubious is my decision to keep
> > slayer a stand-alone application (rather than guile module).
> > It is not a deep decision and could be changed rather easily,
> > but as for now it has proven good at some points (namely,
> > it gave me a better control over the program behaviour while
> > I was creating a Windows port), and a pain-in-the-ass at
> > anothers (it's difficult to create slayer applications using the
> > emacs+geiser methodology).
>
> Our differing choices is a good example of "embedding vs. extending".
> You've probably already read this article
> (https://twistedmatrix.com/users/glyph/rant/extendit.html) but it
> explains exactly why I prefer to extend.
>
> One of Guile-2d's main goals is to work really nicely with Emacs +
> Geiser. I am working on a patch for the Guile 2.0.10 release that will
> allow any Guile program that runs an event loop to integrate a REPL
> server that doesn't have the multi-threading issues present with the
> normal REPL server. So, if you are open to turning SLAYER into a
> shared library, I hope that a free REPL server will sweeten the deal.
> :)

Well, for now I plan to stick to the "embedding" strategy, although I
realize its shortcomings. The big idea is to make sure that every
module that uses SLAYER is able to use all features of multimedia
environment, which should also be simple to use (so SLAYER does not
provide all the modes that SDL or OpenGL do, and binds only a few
procedures from SDL_ttf, for instance).

In the future, if I ever decide to create SLAYER2 that would be based
on SDL2 library, I will certainly make it a loadable module for Guile
-- that's because the specifics of the SDL2 library are such, that you
can create multiple windows.

Since SDL1.2 is tied to one window, I think that it's reasonable to
assume that all the modules can access it in some way.

On the other hand, I think that the architecture of SLAYER makes it
relatively easy to cooperate with REPL (which has actually been proven
with the aforementioned text-area widget). Since SLAYER runs its own
event loop, it's rather straightforward to evaluate Scheme expressions
there, provided that they are available.

However, it is not unlikely that I'm missing something with those
multi-threading issuses. But the solution that I have been using so
far was that I only used supplementary threads only to handle the
network connections, and all the packages that were received from a
socket were being propagated to the main thread using the SDL User
Events.

> > Anyway, if any of you thinks that we could cooperate,
> > I'm really looking forward to it. I'd also like to hear about
> > your goals and ideas, if you're willing to share :)
>
> I would definitely like to cooperate. Perhaps there is a library or
> two that we could extract from our projects for everyone to use.

I think that it might be an excellent idea. There's also this
CPAN-inspired guile-lib project that contains a set of libraries, so
perhaps it would be a good idea to have a module that would be shipped
with Guile and that would allow to easily access some set of modules
from an external repository.

The difficult part is on deciding which things go beyond a
programmer's private language and are actually worth becoming public.
But I think that it's a matter of a good discussion :)

I took an approach such that I have one module that defines a set of
language extensions that I use commonly in my programs, which e.g.
re-exports some popular modules like srfi-1, srfi-2 or (ice-9 match),
and also adds a few of my own extensions. This often saves me a lot of
writing.

Besides I admit that whenever I find it reasonable, I create modules
that do not require SLAYER and go well with pure Guile. The Open
Dynamics Engine wrapper library is such case, that could easily be
taken to another project (however, it consists of a low level code
that requires C++11 compiler to get built)

> My main goal is to apply the Emacs philosophy to game development. I
> want guile-2d to be an easy way to create 2D games interactively using
> the REPL with the ideal environment being Emacs + Geiser. Ideally,
> guile-2d will remain pure Guile and use the CFFI to call out to other
> libraries.

I see. It is a nice philosophy :)
I didn't focus so much on Emacs integration, because I'd like SLAYER
to provide its own editor, that would be more accessible to a broader
class of users (the default keystrokes are always a source of
amusement for the newcomers, and setting up Geiser, although not
particularly difficult, is still non-trivial, unlike setting up the
environment to evaluate Emacs Lisp expressions). Plus I'd like to
integrate it with multimedia content better (Emacs is great for
editing text, but -- despite the existence of such projects as GNEVE
-- it isn't equally good for editing videos or sounds).