hunchentoot VS trial

Thirteen Letters - front end uses parenscript, spinneret, and cl-css; back end uses hunchentoot/hunchensocket

Common Lisp (with http://edicl.github.io/hunchentoot/ )

Not an expert, but I would expect hunchentoot https://edicl.github.io/hunchentoot/ for the backend and a Common Lisp "dsl" generating javascript for the frontend.

Doesn't seem so: https://github.com/edicl/hunchentoot/issues/24

I'd be happy to see a discussion on the issue: https://github.com/edicl/hunchentoot/issues/24

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.