There are many lispgames accounts and lisp game jams but few games. There are 14 games on the lispgames wiki and 70 from all game jams = 84 games. Lispgames has existed since 2010, 8 years ago. That's about 10 games per year, or 1 small game every month.
Outnumbered by Blub
TLDR: For every lisp game, there are 10,000 blub language games. So much for being a "powerful" language.
How many C++
There are 18.2 million programmers in the world, and 3.5 million github
accounts, that is around 1/5 of programmers using github. So lets assume there are 5
* (379 github lisp games + 84 lispgame game jam + wiki) lisp games.
That is 2315 in total. 2315 games in the world.
How many games exist for other languages? (861,000 github repositories * 5 estimated programmers per github programmer) + 1,000,000 android apps that are likely games = around 5,305,000. If we add things like scratch, 36,273,545 scratch projects, its around 40,000,000. What about flash games? Java applets? HTML5 games? My guess is there are hundreds of millions of games made in the entire world.
Lets say there are 10,000 lisp games that have ever existed, but it seems like an over estimate. And there are 100,000,000 million games that have ever existed, which is probably an underestimate. (10^8)/(10^4) = 10,000.
Google Search Poor Examples
TDLR: Many of the lisp "game engines" which are on the front page of google do not demonstrate the power of lisp, they are toys or demos.
See: xelf, blackthorn, sketch.
The Sorry Tale of Those Who Tread the Great Lisp Path
TDLR: Ambition unrewarded
Rewarded for leaving CL for IOS:
There's this guy who paid for LispWorks, had to write his own OpenGL bindings, and eventually moved to ios to create mekorama, which has more than 3 million views on youtube and has been installed on millions of devices. So much for sticking to common lisp.
Gave up on extremely ambitious engine for Unreal:
There was Clinch,
that had ambitious goals, and there were nice 3d demos, but the author
moved to seems to have abandoned it and moved to Unreal. youtube before. youtube after . I also remember reading somewhere we he recommends CEPL instead.
Poor video editing:
Trial looks promising, as in trial's youtube demonstrations. But the only games that have been shared are here.
Then there's shinmera's treehouse which is like a trial tutorial, but
each video is an uncut 2 hours, and there are 39 of them. 2* 36 = 80
hours/ 13 hours watching a day = would take an entire week to watch
Is Baggers leaving?: CEPL looks promising. However, it is starting to look like the author is moving away from CEPL towards TaleSpire.
Difficult to install, difficult to run, difficult to mod, difficult to use
TDLR: There must be an extremely simple installation process.
Most lisp games require a working knowledge of quicklisp, common lisp, common lisp implementations, and the command line. And in order to mod the game you most likely need SLIME + emacs. This basically equates to a tiny subset of Linux users. Where is the one-click install for Windows? Like having a single .exe that just runs? Downloading, running, and modding needs to be a dead simple process, as simple as possible. Complexity of installation drives users away and wastes loads of time. Think of how hard it is to set up a development environment on windows. Examples of projects trying to address this problem are portacle,quicklisp, and roswell.
Lisp games has the social media infrastructure but no content. Despite the proclaimed "power" of lisp, lisp games are less than 0.01 % of market share. Google search does lisp games no favor by providing toy examples. Those who have attempted to create an ambitious CL engine so fervently abandon it at the drop of a hat when they are tempted. Tutorials are lacking. And worst of all, lisp games all basically require time and effort to install and experience with linux, CL implementations, CLHS, quicklisp, and SLIME and emacs.
What could a successful Common Lisp game engine IDE look like?
TDLR: One click install. Runs on Windows. Portable Common Lisp. Portable editor. Very few dependencies. State of the art OpenGL graphics. Dedicated quicklisp installation. Trivial game servers.
- One click install Common Lisp game + IDE on windows, in a similar vein to portacle, but only using SDL2, libffi, and a Common Lisp implementation
- Run on Windows with 96% steam market share. Instead of just Linux, which is around 1.5% desktop market share. 96 / 1.5 = 64, which means the Common Lisp games, instead of being confined to Linux, might run in an area 64 times larger.
- CEPL for graphics
- lem editor using CEPL as a frontend, replacing the arcane installation for emacs
- quicklisp as package manager
In order to understand the true power of Common Lisp, you must understand its greatest weakness.
Common Lisp is unrestrained power. What does this mean? Any one can make a huge mess since there are macros, eval, CLOS, etc. People coming from overly restricted languages like C++ can and will use every "powerful" feature they find to walk code, change semantics of the language, repackage built-in symbols, and do all other sorts of impossible nonsense. Why does this happen? Because when you are weak, like a C++ developer, you never learn restraint. Because of this, Common Lisp suffers from a management problem. If all your developers are using a weak language, there is only so much damage one developer can do. Here is a similar idea by Fare who pointed out that CL is a "hippie language". He has experience managing CL projects with ASDF. There was another blog post by another author about how CL is too powerful but I can't seem to find it.
If all developers could exercise restraint then perhaps Common Lisp could flourish. But this is like saying if everyone in the world was good there would be world peace. That will never, ever happen, except if your world if small enough or everyone is homogeneous. This is why Common Lisp projects start small and stay small. It's like communism, you need everyone to follow the rules. Thus the link between communism, open source, and common lisp.
However, there might be hope for a solution in a lisp that incrementally adds power [at one point the X3J13 committee was debating whether common lisp should be separated into different parts like a "core"] and/or permissions/capabilities like scheme48. I think it was Paul Graham who said that as time passes, weak languages like C++ absorb features from common lisp. Or see Greenspun's tenth rule. In common lisp, everybody gets absolute power no matter what, their is no social hierarchy, thus no government, it's anarchy. That's why fundamentally weak languages with things tacked to mimic Common Lisp on succeed economically but Common Lisp does not. Self plug: I'm trying to figure out how a lisp bytecode interpreter could have capabilities, not extensively, but similar to the JVM.
TLDR: To understand the true power of Common Lisp, you MUST exercise restraint, otherwise you will make a complete mess of things while you are inexperienced.