Hi, as Scott said, I have not introduced myself, my name is Mauricio Fernández, I’m a gamer since computer games exists, and I have been interested in programming since around 1984, when I learned Basic for the VIC-20, some of my first programs were simple games, since then I’ve kept an interest in games, so I know some about it, even without having been part of the game industry yet. I’ve been programming since the 80s, and it is one of the things I enjoy the most.
Some of the people reading (defun games ()) blog posts might recognize my reddit handler (maufdez), I have been active there for a while, since I found the subreddits a little after I began learning Lisp. I also wrote a blog, which I have abandoned for a while now (if you are a follower, sorry about that).
On his last blog post Scott talked about his thoughts about game development in Common Lisp. I’ve been working on the MS Windows side of things, among other things, so I thought I could complement with some of my own thoughts.
While most hackers try to live away from MS Windows, selling a Linux only game is a bit like writing a book in Icelandic, you are limiting your market from the get go (of course there are more Linux users, than citizens in Iceland). But what this means is that we want to write the client to run on Windows 10 too.
In my experience, if you write a program in portable Common Lisp, there is a very high probability that it will run on any platform that has a ANSI compliant Common Lisp compiler. The problem is not Common Lisp, you start getting into issues when using libraries that depend on a Foreign language, specially in windows where these depend on DLLs. So you say, that proves it, Common Lisp is not mature enough for game development, but the truth is that a lot of the problems you get are also present in other programming languages, the proof is that you can find questions about the same problems in forums dedicated to Python, Java, and even C, C++, and others.
I tend to try to avoid FFI libraries whenever I can, but unless we are willing to reinvent all kinds of wheels, we have to use things like sdl2, qt (or similar), OpenGl, assimp, and others, and that sometimes means that your program will fail in the foreign call, or loading the foreign library (which may fail because a third DLL that you don’t know about).
The problems with foreign libraries are not limited to Windows, you might run into similar problems going from a Linux distro to another, and , as I said, in most cases the problem is not a Common Lisp problem, and developers working in other languages run into the same issues.
The good news is that we know that these libraries worked on some C or C++ project, with the right SOs or DLLs, so it should most likely also run on Common Lisp, and that is what we have found so far. Which means that, with perseverance, we can get our game working, and learn how to smooth all the wrinkles, and that is part of the value we get from this, “Game 2” should be easier to develop once we know where the bumps on the road were when creating “Game 1”, and so forth.
A lot of the libraries we are using are a labor of love. As far as I know Baggers does not receive any remuneration for developing CEPL, and I think neither does Shinmera for working on Qtools, to mention just a couple, some projects are more complex than others, going from simple bindings, to completely lispified ways of writing code, so the parts are there, we have to piece them together, document our findings, and help to improve the existing tools however we can.
I think that making games, will improve the tools, which will make it easier to produce more games, which in turn will show us more ways of improving the tools, and that continuous spiral will make Lisp as good or better than other languages in terms of game development, and I think we have enough people writing (or trying to write) games to make this happen.