Spring Lisp Game Jam 2023

I didn’t read in depth yet, but in the past I found that generating mazes by removing walls (instead of entire squares) produces nicer looking results (but of course has a different data model!).

screwtapeSubmitted363 days ago

Very cool. I think the Wikipedia page talks about different properties of different maze algorithms (longer straight corridors .. always connect start and exit ..) but it's a big and deepy mathematical thing isn't it.

I'm trying to do a maze now too, but instead of walls there's a time constraint and a travelling salesman problem, basically ;p though I will just write it up tonight.

If I understand your movement happens on keydowns? What do you think about holding down buttons?

It's nice following your commented thoughts through the sequences of code.

Vito VanSubmitted363 days ago

> it's a big and deepy mathematical thing isn't it

It is! It scares me badly.

Ah, traveling salesman problem, that also scares me, I would like to play the game though.

> If I understand your movement happens on keydowns? What do you think about holding down buttons?

Yes, it is. I didn't handle the "holding down" action specifically, instead I let SDL2 to handle it. It seems that SDL2 will generate KeyboardEvent repeatedly, in the game the player just goes ahead again and again.

There seems like to be a data field to detect this:
https://wiki.libsdl.org/SDL2/SDL_KeyboardEvent

It's nice to know that you are also on SDF.org!

screwtapeSubmitted362 days ago

So the way my one is working is like this C (inside my lisp):

const Uint8 state;
state = SDL_GetKeyboardState(NULL);
if ( state[SDL_SCANCODE_UP] ) printf("Up is currently held down");

I'm not sure what that looks like in your lisp binding though!

Vito VanSubmitted362 days ago

In Lisp I use with-event-loop from cl-sdl2, like this:

(with-event-loop (:method :poll)
              (:keydown
               (:keysym keysym)
               (let ((scancode (scancode-value keysym)))
                 (cond ((scancode= scancode :scancode-space)
                        (format t "Playing Song~%")
                        (sdl2-mixer:play-music music 1))
                       ((scancode= scancode :scancode-up)
                        (when (< (+ *current-volume* 20) 128)
                          (incf *current-volume* 20)
                          (format t "Current Volume: ~a~%" *current-volume*)
                          (sdl2-mixer:volume-music *current-volume*)))
                       ((scancode= scancode :scancode-down)
                        (when (> (- *current-volume* 20) 0)
                          (decf *current-volume* 20)
                          (format t "Current Volume: ~a~%" *current-volume*)
                          (sdl2-mixer:volume-music *current-volume*))))))
......

I think the above code is just like some of your code here :

for (;;) {"
    "
    while(SDL_PollEvent(&e))
        if (e.type == SDL_QUIT) quitted = 1;
        else if (e.type == SDL_KEYDOWN)
            switch (e.key.keysym.sym) {
            case SDLK_q:
                quitted = 1;
                break;
            }

I didn't handle the "holding down" action specifically, so I haven't used something like SDL_GetKeyboardState.

If I were going to do it, I could use the function `keyboard-state-p` as defined here:

(defun keyboard-state-p (scancode)
  "Whether the key corresponding to the given scancode is currently pressed."
  (let ((state (nth-value 1 (autowrap:inhibit-string-conversion
                              (sdl2-ffi.functions:sdl-get-keyboard-state nil))))
        (scancode-num (autowrap:enum-value 'sdl2-ffi:sdl-scancode scancode)))
    (c-let ((state :unsigned-char :ptr state))
      (= (state scancode-num) 1))))

I can see that you're using ECL SFFI in your code, which involves writing C in Lisp, why not using UFFI or CFFI, since it will give us a more Lispy programming experience? Just being curious, because I feel C is too intimidating to me.

screwtapeSubmitted362 days ago (1 edit)

In some of my deployment contexts I have found ECL (ie just a C lib) more often supported than cffi, and I am somewhat used to C (it's a domain specific language for working with C operating systems in lisp, right).

I guess the c2ffi autogenerated stuff is nice and complete, on the other hand I think a la carte is also nice (alright, maybe shouldn't call writing C nice...).

Edit: For example if I were to want to conditionally pledge my game on openbsd in ecl :

#+(and openbsd ecl)
(progn
 (ffi:clines "#include <unistd.h>")
 (let ((ret 0))
  (declare (:int ret))
  (ffi:c-progn (ret)
   "#0 = pledge(\"stdio rpath\", NULL);"
   (unless (zerop ret) (error "pledge"))))
(mapc 'print (directory #p"./*.*"))
(uiop:quit)

it's not clear to me that I would have gained a lot by dragging in https://github.com/cffi-posix/cffi-pledge . Though this example shows how gnarly sffi is too I guess !

Vito VanSubmitted362 days ago(+1)

Ah, BSD pledge! This is so elegant, I never heard of it before. Once I used FreeBSD as the OS of my PC but uninstalled due to some lack of WiFi drivers reason, but I still remember the clean and tidy FreeBSD Handbook, quite nice.

"a la carte" is indeed nice, you could deliver your work in a thin and slim way, as for CFFI, I have to pack all those .so/.dylib/.dll with my game, which is kind of over "table d'hôte".

screwtapeSubmitted361 days ago

It's in the openBSD libc particularly but yes, it's very nice. Nobody actually wants to try using Security Enhanced Linux but every openbsd dev uses this (and then you describe your package as being pledged and unveiled). Now, can I actually add this to my game jam game release ;p

Vito VanSubmitted363 days ago

> nicer looking results

Wow... that's my dream, I dreamed something like this:

https://watabou.itch.io/one-page-dungeon

But I don't think I have enough time for this jam, maybe the next time, in the autumn.