calysto_scheme VS trial

Oh God, Newlisp. Don't worry about that. Start with Common Lisp. It's probably the most Pythonic in that it's built for building real applications in. SBCL is the open source implementation everyone seems to favor.

Runners up are Racket and Guile.

The "Lisps in Python" (like Hy and Hissp) are nice, but they're not very Lispy. More like Python with sexpr syntax. I recommend Calysto Scheme for messing around: https://github.com/Calysto/calysto_scheme

It's slow, but it's full Scheme.

Little Spark - made with Trial

The engine is called Trial. https://github.com/shirakumo/trial.

I don't know what the situation is like for 3D game programming in CL. Shinmera recently kickstarted a game but it's 2D I think and I don't know if his engine (https://github.com/Shirakumo/trial) does 3D. But regardless of what you're using, going into learning how to program while also trying to learn how to use the game engines available in the CL world will probably be a recipe for getting overwhelmed and discouraged. I'd recommend going through the Steve Losh post first and reading A Gentle Introduction to Symbolic Computation and/or Practical Common Lisp to get some solid general familiarity with using CL. Both are available online for free. You can also browse through the Cookbook: https://lispcookbook.github.io/cl-cookbook/

For graphics there's a lot of different variants and options. I use Trial, but that doesn't have any docs yet, I'm afraid.

Kandria and Eternia both are built on top of the game engine Trial, which I and a few others at Shirakumo have been working on for some years now. Trial itself makes use of a bunch of lower level libraries like cl-opengl, GLFW, pngload, harmony, etc. but a huge amount of the codebase was written by me. If you're interested in its development, I recommend hopping by the #shirakumo channel on the Freenode IRC network. I'd be happy to answer questions there!

A good way to do it is to keep a staging area of sorts that keeps track of the manually allocated objects and their state. When you allocate you batch all objects to allocate together and then execute the load in one go, updating the records in the staging area. Then, when you're ready to switch to a different scene or whatever, you diff the staging area against the current set of objects that need to be live and deallocate everything else in one go.