Common lisp: portability

Question

question

If I make a 2d game in common lisp (uses: lispbuilder-sdl, quicklisp, cffi) using clozure cl on windows, will I be able to easily port it to other platforms (linux/iPhone(maybe)/android) later? Is lisp "suitable" for installable programs?

information

1. The game will use OpenGL for graphics. Most likely it'll use sdl for input/opengl initialization, and either sdl or openal for audio. Might end up using my own library instead of sdl later.
2. Writing few C++ libraries for cffi (to wrap functionality in "portable" way) is not a problem.

reasoning

I'm really, really tired of C++. Want to try something (that is not python) with simpler syntax + more power. Have a game project in mind, want to know whether choosing lisp for a game means serious trouble if I suddenly decide to distribute/port the game later.

--edit--

additional info

What do you mean by "suitable" and "installable programs"?

I'm not sure how well CFFI/quicklisp will play if I try to turn finished program that can run onto my machine into installable package (windows installer on Windows, for example). quicklisp, for example, sets up paths/repositories within user's home dir (which might not be acceptable behavior) and tries to download packages automatically from external sources, which is not a good thing when you try to distribute program and make sure it works as intended. CFFI at some points "binds" foreign libraries to lisp functions, and it is unclear for me how well it will work, say, if I dump program image, embed it into exe and run said exe on another machine. According to common sense, that should work just fine as it is, but in the worst-case scenario it could result in me having to write complicate installer specific to lisp distribution.

Answer 1

** NOTE: Sorry if I state the obvious in this post, I'm not sure of you familiarity with Common Lisp**

Carrying on from sds:

There does seem to be a bit of life on getting clozure running on android but the performance available remains to be seen. It is very unlikely that we will get to see lisp games in the iphone store unless they compile to some other language where the compiler is not available at runtime (See Nu or for a proprietary option see mocl which both have ways of addressing this issue)

Portability - Across Implementations

In libraries it is definitely worth while to get them working portably across as many implementations as possible, however for games I'd really just pick one implementation and hone your code on there. You will probably be distributing your game as a package for each platform as opposed to through quicklisp right?

Portability - Across Platforms

Do make sure to check out the progress of you preferred implementation on each platform, there can be subtle gotchas. For me I use SBCL and under Windows only 32bit is fully supported, whilst 64 is still under development.

Packaging

This has some good timing for you as some information on packaging Clozure apps for Apple Mac Store was posted on openmcl-devel today . I haven't had a good read yet but the thread may provide more info.

Zach Beane has also made buildapp for SBCL

The lispbuilder folks also seem to have some info on making standalone executables.

Tools

cl-opengl is a very good wrapper for opengl. It supports both old and modern opengl styles and so I find the areas which try to provide higher level abstractions a bit limiting (I personally steer clear of cl-opengl's gl-arrays). Do have a read of the source though as the is some great stuff there, especially when you start writing more cffi code. {cl-opengl is still being developed and available through quicklisp - I have used it under linux and windows happily}

lispbuilder-sdl is very cool but again you may find the urge to take control of some areas. For example the sdl:with-events macro is great, but takes control of your main loop and time-step handling. This may work perfectly for you but if not don't be afraid to dig around and write something better to replace those parts!

Also lispbuilder provides a range of libraries so before using them check if there is a more recent equivalent in quicklisp. For example lispbuilder has lispbuilder-opengl. Don’t use this, stick with cl-opengl. Again lispbuilder has lispbuilder-regex while it is probably much better to use CL-PPCRE.

I probably wouldn't recommend use it as it stands but I spent a little time a while back stripping out all of lispbuilder-sdl that didn’t pertain to modern opengl games (so no sdl software surfaces etc). I DON’T think people should use this yet but it may give you some ideas! {lispbuilder isn't under heavy development but is available through quicklisp - I have used it under linux and windows happily}

Also whilst I am pimping code written by great people and then torn apart by me, see this video on how to recompile parts of your game whilst it is running. It is not my technique but does work very well.

The above will require you to be using SLIME or SLIMV which means using either Vim or Emacs. SLIME is really worth your time so do have a look!

All in all, good luck, common lisp is great fun to develop on and while you may find it takes a while to get an opengl work-flow you enjoy, if you have the time I have no doubt you will have a great time.

Look forward to seeing the game!

Answer 2

Portability

You have to distinguish between portability across platforms (e.g., will your program developed under Clozure on Windows run on Linux?) and across implementations (e.g., will your Clozure program run under SBCL?)

You will need to carefully examine the details in the specific implementation manuals, but, generally speaking, if you use the standard CL functionality plus CFFI, you should not have any major issues in either aspect.

Practically speaking, you need to examine how well Clozure runs on the platforms you are interested in and whether CFFI supports Clozure on those platforms. These questions are best asked to the developers, not here.

Installability

All CL implementations do "product delivery" in some way, e.g., by creating stand-alone executables which you can then packages and distribute.

Answer 3

will I be able to easily port it to other platforms (linux/iPhone(maybe)/android) later?

Well, it depends largely on the libraries of you choose.

I don't have any experience with Android or iOS development at all, but I'm currently developing small project in Common Lisp, wich uses lispbuilder-sdl, cl-opengl, quicklisp, etc, and there were no problems porting it between SBCL on Linux to Clozure-CL on Windows.

Also, there is at least one promising mobile Common Lisp implementation: https://wukix.com/mocl

So I think you will have no problems porting your code, just be sure that all libraries used in your application have appropriate support on each platform and Lisp implementation.

Is lisp "suitable" for installable programs?

Most Lisps have ability to create stand-alone executables with embedded libraries. On the other hand, if your project grows large enough, you will have to write platform specific installers regargdless of possible Lisp-related problems. And I doubt that Lisp-related part turn out to be the most complex. Also check out this post: Lisp Executable, and consider the idea of distributing Lisp runtime images instead of standalone executables.

Answer 4

For using Common Lisp as a game runtime there are excellent answer already.

I just want to mention that PlayStation 2 games Jak and Daxter: The Precursor Legacy and Crash Bondicoot are developed using Common Lisp in a slightly different way.

They had their developing environment in Commmon Lisp and made a game language, GOAL (later GOOL), that was a high level language with assembly inlining (Like C's __asm__). The product thus has little to do with it's development environment when the end product was compiled.

They only targeted one platform (PS2), but I imagine one could make language constructs so that you may optimize for several platforms using almost the identical method. Making Game language would abstract away actual hardware and library differences and keep the complexity of a compiler lower than to try compiling Common Lisp to e.g. Dalvik directly. the compiler doesn't really need to end up as object code either. It could compile to C/Java/Objective C.

The portability issue then becomes something you control by looking at some preferred target when designing your language and how to make package/binary can follow the ways of the target.