Spycursion is now on Patreon!

We’d be honored to have your support on Patreon.

Just want to follow progress? You can join our mailing list here:

Out With the Old, In With the New

The Launch

On Feb. 26, we launched our Kickstarter campaign in the hopes of funding the rest of Spycursion’s development. Our spirits were high (even if our energy levels weren’t), we hit 2% funding within a few hours, but most of all, we were just excited for our studio to move into a new phase of its life. We had lined up PR contacts and were running a really clever — perhaps too clever — marketing campaign. At that point, all we had to do is wait for the inevitable surge in backers.

Early Bird

Admittedly, we should have seen the signs. By Day 3 I was beginning to, but to be completely honest, I spent most of the first three days of our campaign so exhausted from the preparation of it that I could do little else but refresh social media feeds and ask Mauricio why more backers weren’t coming in. The press weren’t responding to us in nearly enough volume, our ad campaign was a total flop, and our mailing list on its own wasn’t large enough to drive the early traffic we needed. We had focused all of our energy on that 72-hour period, and it netted us a whopping 4% funding. I was about to call a pow-wow with Mauricio and Dan to figure out how we could save this floundering campaign. Until…

CRACK!

Did you hear that? That was the sound of my wife breaking her wrist (in a very complicated and interesting fashion, she says). So, yes, I spent much of the next week focusing on her rather than our Kickstarter campaign.

The Doldrums

By the time I got back into things, our campaign hadn’t advanced much further and we all agreed that it was more or less doomed. That’s when we made the decision to move to Patreon and shared this update on the Kickstarter page. Since that update, Mauricio and I have been working on said Patreon page, discussing our new development plans… and looking for jobs. C’est la vie.

The Future!

As you may have already gathered, development on Spycursion will continue! It will be at a slower pace, no doubt. We almost certainly won’t be able to hit the Q4 2020 goal that were aiming for with the Kickstarter campaign. On the upside, if we can get our sustainable funding situation worked out, then you’ll have happier, less stressed-out devs working on the game — which means greater productivity and fewer bugs!

For now, we’ve launched a Patreon page to serve as both a funding boost and a barometer of how our fans are feeling about the game. Right now, our membership tiers are very simple: For every month that you back us, for an amount of your choice (more on that in a minute), you get one month of Spycursion gameplay after it’s released. We will certainly add more tiers, and possibly raise the minimum price tier, as time goes on. For now, we’d just like to know what our supporters want in terms of rewards. Let us know if you have reward ideas or other thoughts on our Patreon page!

In diagnosing the non-success of our Kickstarter campaign, one of the conclusions we reached is that the pricing and value we offered didn’t line up. Our pricing was based on a fuller, more polished version of Spycursion that we had in our heads — rather than reflecting the presentation that we were able to showcase at this stage of development. People don’t see what’s in our heads, they only see what we can show them, and what we could show them didn’t justify the price points. (And yet, it clearly did, for those who backed us. A friend pointed out that some backers were willing to pledge over $200 for a game that’s 18+ months away! That’s certainly not nothing!)

This is why the “pay what you want” model we’ve adopted on Patreon is key. We’d like our supporters to think carefully about what they see, what we’ve shared, and our own capabilities, to decide what a month of Spycursion is worth to them… and then tell us! At this point, we’re expecting a lot of $1/month backers, and that’s perfectly fine. Over time, we hope to earn more supporters and more trust. The nice thing about Patreon is that we don’t have to get everything right at the beginning; our fans can help us over a longer time period in molding Spycursion into what they’d like it to be. We hope you will join us on this journey!



The basics of game programming in Common Lisp.

Common lisp is a wonderful language, a lot of people tend to think it is a functional programming language, and while that is not a bad thing, Lisp is not a functional programming language, it is a multi-paradigm programming language. While it is not considered good Lisp style, you can program in an imperative way; Why am I telling you all this? well, because people always object that being functional makes it difficult to program games, which is not completely true either, but Common Lisp will work with you and not force you to work around it.

While I am in the theme of fallacies, another false misconception about Lisp is that it does not have libraries, it does have more than a descent amount of native libraries, Common Lisp implementations also have FFIs which has allowed to create bindings to very useful C libraries, and since bindings are commonly not “Lispy” some times we have great adventurers creating wrappers that made them feel like they were written for Common Lisp.

So, What do you need to program a game?, in the simplest terms you need:

  • Output: A place to show text, graphics, lights, sound or whatever your game uses for interaction with the user.
  • Input: Devices to interact with the game (i.e, move the character, move icons, write text, etc).
  • Assets: Different types of things that go into your game (images, models, sounds, maps, music).
  • Constraints: A set of rules that physically or logically constraint the actions that you as a player can do (i.e. physic engines)
  • Logic: A set of rules that affect how the user interacts with elements in the world. (i.e. open a chest, a door, use a computer etc)

    You might argue there are more things, but to me this five make the core of what you need. So lets break this down for Spycursion, which is our game, I will intentionally leave out the socket magic happening between the client and server, which is necessary in any MMO.

    There are two types of interaction in our game, the Computer GUI and Terminals and the 3D world.

    Spycursion Computers

    Input/Output

    The computers in Spycursion are meant to look like real computers, once you start using a computer you will either see a GUI environment or a Terminal, so what we need here is a GUI library, we could (and actually thought about) write one from scratch, but with so many solutions in existence out there we decided to use one with the characteristics we needed, and the winner was Qt, one of it’s redeeming qualities being portability, which is important when you are writing a game that runs in Linux, Mac and Windows. To write our Qt in a lispy way we use the fantastic Qtools library written by Nicholas Hafner (a.k.a Shinmera).

Assets

Qt provides the necessary tools to import icons, images, play sounds, and even render html, so it is relatively easy to get a full screen application that looks like a computer desktop.

Constraints

Constraining a GUI is very easy, you just provide the programs that you want people to be able to use, and what those programs are capable of doing. Constraining a terminal is even easier, you just decide what commands exist and how they interact with others (piping, I/O). In both cases you can restrict user rights, so it ends up being a bit like real life system administration, but with more control.

 Logic

Implementing Logic in Qt is very straight forward, you can decide what happens when you press a button, hit enter, change text, etc.

I won’t provide examples because there are plenty on the Internet.

Spycursion 3D World

Output

Since we are shooting for a 3D world the safest bet is to use OpenGL, Lisp has the cl-opengl library, but that is too verbose, the good news is that Chris Bagley (a.k.a Baggers) created CEPL, which has as a design goal, and I cite “… making the user feel that GPU programming has always been part of the languages standard.”, asides from that promise, Baggers has spend hours doing great videos which he has shared on Youtube.
To run OpenGL you need what is called a surface, which is basically a graphic container, when we started doing this the only stable option for CEPL was SDL2, so we to use cl-sdl2 too. The library, in this setup, is used only to have a display window, but it is capable of a lot more, as an example you can look at sketch, which you could use to create 2D games.

Input

A lot of the things we care about were also concerns to Baggers, and he has a whole ecosystem of related stuff, some of which even come installed with CEPL or are part of it, for Input his contribution is called skitter, which allows us to detect mouse movement, position, clicks, keyboard presses and all that jazz, it can even handle game controllers. While we use it with CEPL it is independent of it.

Assets

So far we have been worried more about showing a 3D world, some menus and text, so I will talk only about those aspects, of course there are options to import and play sound, but I will focus on 3D models. You should be able to use a 3D modeling program to create your assets, save files, and get the data from those files imported into your program, that is the job of the great assimp library, and of course we have classimp which is classier ;-), with that library you can import several 3D model file formats, so you can use a variety of programs to create your model, including free options like Blender, or you can buy them in a format you can use. Of course this only creates a data structure, so you have to do all the wiring yourselves, but you will be able to import models including the animations which you need for your game.

Constraints/Logic

All constrains and logic are programmed in Lisp, with some help from stenciling, this is one of the few instances where we used cl-opengl directly instead of using the CEPL scaffolding. In general Common Lisp is a very potent programming language, so writing logic in it is very straightforward and flexible. We are currently not using physics engines but there are libraries for that too.

Some final thoughts

There are many wonderful tools you can use to make your game, we are just talking about the ones we used, you could use Xelf for 2D games, or Trial for 3D and 2D, there are libraries for text rendering both in 2D and 3D, libraries to do text based games (i.e. cl-ncurses), tools for importing and playing sound. There have been games written in Common Lisp in recent years, and there are Common Lisp game jams (the next one starts on April 18th, 2019), the fact is that writing games has been improving the ecosystem.

If you ask for it, we could expand in some of these themes, but the basics are the same, choose the type of game you want and the look for it, choose the adequate input and output libraries, add suitable libraries for importing assets, use some libraries for collision detection and physics if necessary, add your own logic, mix everything with tons of creativity, and you’ll have a game.



The Spirit of Kickstarter

Kickstarter has changed a lot over the years. Observe this video game project from 2012… and then observe this one from 2018.

Go on. I’ll wait.

In 2012, a tiny independent game studio could launch a campaign without so much as a video trailer and net $150,000 in funding. Meanwhile, in 2018, established studios learned they could repackage their old releases, toss them onto Kickstarter with some collectors’ items, and fund a successful campaign literally overnight.

Don’t get me wrong, I loved the Myst games. But I can’t help but feel that’s not really what Kickstarter is for, ya know?

Some people have told me that we shouldn’t be launching a Kickstarter campaign. “You aren’t a big studio with an established audience.” “Your graphics aren’t very good yet.” “You don’t have gobs of marketing dollars.” All of those things are true. I certainly wish inspiration had struck back in 2012, when those weren’t necessities — we might have surged past our funding goal a long time ago.

But instead of looking at the cards we weren’t dealt, let’s look at the ones we were:

  • An innovative concept in an underserved niche. I truly believe that enough people exist who would be excited enough about Spycursion to back it, as long as we are able to find that audience. (Not always an easy task!) When and where we have found that audience, we’ve received a lot of praise. (And a handful of naysayers, usually related to one of the “cards we weren’t dealt” above.)
  • Secret alien technology. We haven’t played up Lisp too much as an advantage, partly because it’s still largely uncharted territory for game development. But both Mauricio and I have often been surprised by how easy it makes certain things. If When Spycursion happens, I won’t say it was only because of our choice of programming language… but I will say that that choice probably helped.
  • A small, but enthusiastic, fan base. That’s you! And, it turns out, you may be the most important part of this whole equation…

It’s important to realize that indie studios like us are no longer competing against the likes of Starlight Inception for visibility on Kickstarter. We’re competing against Myst, and if we try to compete on traditional grounds, we’ll get creamed every time. We’ve done our best so far to put those first two advantages above to good use, but the third one is mostly out of our hands. That’s where you come in.

And yes, this is the part of the blog post where we shamelessly ask you to share Spycursion with all of your family, friends, enemies, acquaintances, ex-lovers, and every random person with whom you make eye contact but don’t click the Back button yet because there are good reasons why you should do so!

If you’ve spent any amount of time browsing Kickstarter, you’ve probably seen those projects from very non-startup companies with high-budget videos and suspiciously low funding goals. You know, the ones using spammy crowdfunding agencies, the ones that make you think to yourself: “This entire campaign is solely for publicity, isn’t it?”

Well, we’re the antithesis of that. We’re just a couple of people with some ideas and skills who came together to bring a game to life. As a brand new, zero-budget studio, we’re using Kickstarter for its original intended purpose — to “kickstart” a creative project! Kickstarter is, and always has been, our Plan A. (There are contingency plans — all of which have significant downsides — but those are better off in another post.) Sadly, that also means we’re facing some headwinds that we arguably shouldn’t have to face. That’s why your support (financial and/or social) is crucial to our success.

Do you love the concept of Spycursion and the long-term vision we have for it? Splendid! Share. This. Game.

Do you love the concept of Spycursion but hate how the graphics look right now? Excellent! Share. This. Game. With the support of you and all your family/friends/enemies/etc., we can afford some better art and all of the graphical bling-bling you can handle.

Do you love the concept of Spycursion but are skeptical that we can actually pull it off? Glad to hear it! Share. This. Game. With the enough support, we will pull it off, and if for some reason we don’t, we’ll be open-sourcing the whole shebang for you to try pulling it off yourself. (See the “Risks and Challenges” section of our Kickstarter page.)

Do you hate the concept of Spycursion altogether? Cool beans! Share. This. Game. You never know who else might enjoy it in your stead.

Did you come from /r/lisp or Hacker News and you just want a Lisp game to point to when people trash your favorite language? Superb! Share. This. Game.

Share our Kickstarter page. Share our trailer. Share this blog post. Share it on Facebook. Share it on Twitter. Share it on Reddit, or Mastodon, or Pinterest, or whatever your favorite social networks are. Share it on 4chan just kidding please don’t do that. Share it on your blog. Share it on a postcard. Share it at parties. Share it especially with people you know who happen to be in media and/or very rich. Share. This. Game.

With enough sharing (and broken records), we can bring Spycursion to life. That, in my opinion, is what the spirit of Kickstarter is all about. Thank you for your support!





Some things we’ve learned developing a 3D game for Lisp.

Hi, Mauricio Here,

This blog post is kind of a developers blog, as I said in my only previous post I’ve been dealing with the MS Windows side of things, I also made some 3D models using Blender, and use the abstractions Scott had created to create a a new scene for the game (a bedroom), but of course my job has not been limited to that. We’ve learned some stuff that we would like to share, so that is what I am doing.

Classimp on Windows.

One of the earlier lessons we learned was related to Assimp, for one thing downloading the binaries and moving the dll to your project directory does not work, in recent Assimp versions the name of the dll isn’t even one of the names searched by Classimp, and renaming or making the code match the dll name does not do the trick. In order to make classimp work we had to compile with gcc instead of visual c, using mingw,, this produces a libassimp.dll which is what classimp looks for and that DLL works fine. The latest Assimp library supported by Classimp is 3.3.1, so if you want to compile it yourself download that version and then follow the instructions here.

When you compile with MingGW using the instructions in the link the DLL will be in the “assimp-3.3.1\build\tools\assimp_cmd” directory, and asides from that you get an assimp.exe executable that is very useful for asset conversion. Currently we are consuming fbx files, so when I created models in Blender I exported them as fbx files, and that caused problems in some cases, so we adopted a different  workflow which so far guarantees a model that loads correctly in CEPL, we use assimp.exe in the command line to convert the .blend to .dae which is the extension for Collada, an open exchange format, and then use Autodesk FBX Converter to convert the .dae to .fbx. This workflow gives you better control over the way that the files are converted.

Why not reading the .blend files directly?, Well for one thing we had some pre-made assets and those were fbx, and we want to be uniform., another reason is that sometimes the file would not be read correctly by classimp, but assimp.exe tries several stuff and is able to export it, as long as you remove any lamps form the scene (I also remove the cameras for good measure). And a third reason, is that sometimes we want to pre-transform the vertices  specially with several objects in the same file, and doing this during the export simplifies the code to read the file. So we do use this:

assimp export file.blend  file.dae -ptv

In the command line, where -ptv stands for pre-transform vertices, and assimp guesses the output file format from the extension of the second file. Assimp does not export fbx , that is why we export to ,dae and then convert. Classimp can read .dae files correctly, but fbx files are smaller, and the difference in load time is negligible for our purposes, and as I said we want to keep uniformity.

Another good tip is to use the assimp viewer to open an asset, and then look at the log file, this will warn you of possible problems when importing with classimp.

Multiple Textures in one Mesh.

We ran into a problem with a model of an avatar we were using in the game, the textures were not imported correctly, the head texture was applied to the body, so the model looked like it had no pants, and it had some weird things in the skin (actually stretched head features). The problem is that when you run (classimp:import-into-lisp) each mesh object contains only one texture. however the model had a mesh with two textures.

Luckily Blender allows you to select the portion of the mesh that is assigned to a particular texture and separate it. So we separated the head from the body, re exported, re-sorted the textures and voila, problem solved.

How do you know the order of the meshes? Well, the first thing is to name things right in Blender, then the structure you get when you import into lisp has a tree and that gives you the clue.

SPYCURSION-CLIENT> (ai:import-into-lisp (car *char8-data*))
#<CLASSIMP:SCENE {100A0E4AE3}>
SPYCURSION-CLIENT> (ai:root-node *)
#<CLASSIMP:NODE {1004FA9443}>
SPYCURSION-CLIENT> (ai:children *)
#(#<CLASSIMP:NODE {1004FA8663}> #<CLASSIMP:NODE {1004FA8903}>
  #<CLASSIMP:NODE {1004FA8B93}> #<CLASSIMP:NODE {1004FA8E33}>
  #<CLASSIMP:NODE {1004FA90D3}> #<CLASSIMP:NODE {1004FA9373}>)
SPYCURSION-CLIENT> (loop for x across * collect (ai:name x))
("Head" "Gadget" "Bag" "Body" "Jacket" "Hair")
SPYCURSION-CLIENT>

So the first mesh is the head, the second the Gadget, and so on. The pre existing textures worked well because I just separated and saved again so the UV coordinates remain intact,  now each mesh reads from the right image, and maps the right coordinates.

Blender

One of the models I was making was a full room, to do it I used Archimesh, the room was simple, a rectangular room with a window and a door,  and some cabinets, this worked out perfectly in Blender, but not so much when I imported the models in CEPL. The thing is that boolean operators produce weird geometry, and the holes in the walls for the door and window are produced by boolean subtraction. In other models the sub surface modifiers looked like crap when imported,

So I decided to re-make the room the old fashioned way, loop-cuts and face deletion, replace the old room, and apply all of the modifiers to other objects before exporting, that way the look was predictable.

The other thing I learned is that you need to either use the a processing flag in classimp or export the model with pre-transformed vertices, otherwise the objects in the scene were not placed in the right position. I used Blender to lay out the room furniture, and then exported each element separately, that made it easier to place and remove things, and handle the textures.

I also spend some time baking textures, and exporting the UVs, the UVs exported from Blender are immediately usable, and you can use DIRT to import the texture, so asides from the tedious process of UV wrapping the objects, assigning the image, and baking the textures into it, the process is very painless.

Final Thoughts

After ironing out the exporting problems saving models so they can be used with CEPL turns out to be a straight away process, there are some things in our code we are optimizing to make the process of maintaining the software and adding stuff more straight forward, but we have a working skeleton,  we can create rooms and cities, place avatars, animate them,  etc.

Of course there is still work to do, and Spycursion is curious in that it has two environments, the OS and the 3D world, but even when we some times hit ourselves against a wall, there is always a door a couple of steps away, as we learn more is like turning the lights on, we now where the walls doors, windows and other stuff is, and that allows us to move freely.



Our Kickstarter Launches February 26th!

We’re excited to remind you that our Kickstarter launches February 26th!

We’ll share the pre-launch page with you when we’re ready, but we’re looking for $100,000 to help us get Spycursion off the ground.

We’ve got some exciting backer rewards planned, so we hope you’re hyped!

For more information on our plans for Kickstarter, see here.

Check out our trailer if you haven’t already for an idea of what Spycursion is all about.

Don’t forget to follow our Twitter to keep up with what we’re up to!

What is Spycursion?

We’re glad you asked! Spycursion is our “edutainment” hacking MMO that aims to teach players how to hack and code. We want to get people more invested in the world of programming.

Spycursion may be educational in nature, but it’s as much a game as a learning tool. Expect more details on the MMORPG aspect of the game in the future!



Introducing myself (Mauricio)

Mauricio's Picture :-)
Don’t be scared is just my face

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.

About Portability

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.

Releated Links

Reddit: u/maufdez
Twitter: @MauricioFdezF
Masstodon: @maufdez@fosstodon.org
Github: maufdez
Blog: Funlisp
Google+: MauricioFernandezF



Creating a (Non-Trivial) Lisp Game in 2018

Lisp programmers are a small group. According to the TIOBE index, Lisp currently sits at #32 on their ranking of programming language popularity. (Common Lisp specifically is somewhere between 51 and 100.) You can certainly imagine that Lisp game programmers are an even smaller group. And then when you consider non-trivial games, the games made by teams, the ones that are significant enough in scope to potentially fund the studio building them… well, I don’t think it’s much of a leap to say that you can probably count the number of those games on one hand.

Suffice it to say that not a whole lot has been written on the art of developing games in Lisp, relative to other languages. As a leader of one of the aforementioned five-or-fewer teams building a sizeable Lisp game (Common Lisp, in our case), I want to contribute to that collective knowledge base. But first, a caveat: It would be premature to consider either (defun games ()), as a studio, or myself, personally, as any kind of “authoritative voice” in the Lisp game community. Spycursion is the first game that we as a studio are producing, and it hasn’t even been funded yet. (Hint hint, Kickstarter, Feb. 26, hint hint!) And although I was a hobbyist Common Lisp developer for about seven years before starting work on Spycursion last year, there’s still a lot about this language I don’t know, and there are certainly people who could write better/faster Lisp game code than me… I’m just the only one who was insane enough to start this project. 😉 We also recently picked up another developer (he hasn’t introduced himself yet, but he will) whose opinions may differ from mine. Taken altogether, what I’m trying to say is: I’m not a guru. I’m just one guy trying to find his way on this bizarre-yet-beautiful landscape, just like everyone else!

Aaaanyway, Lisp games. The first thing you should know, before you go tell all your friends “Hey, they wrote Spycursion in Lisp, let’s create our Overwatch/Pokemon/Dark Souls cross-over in Lisp, too!” is that Spycursion is weird. The game itself is weird, its architecture is weird, its developers are weird… Point is, we’re working with some parameters that make Lisp not only suitable for Spycursion, but perhaps even the ideal language for it. Your Overwatch/Pokemon/Dark Souls cross-over may not fit the bill. (Or it may. I’ll let you know after we release Game #2.) It’s also important to remember that Spycursion has a client and a server component, both of which are written in CL. This was not always the case for the client; I’ll share that story in a minute. But let’s talk about the server first.

As we’ve mentioned before, Spycursion has its own programming language. You may have read about how domain-specific languages (DSL’s) in Lisp are grand, how they’ll make your coffee for you, blah blah blah. In my experience, a lot of the conversation about this can get pretty academic, but here’s a summary of what happens when you compile and run a Slang program in the world of Spycursion:

1. Compilation: The server parses your program (assuming it is syntactically correct) and creates a tree of Lisp forms from it.
2. Runtime: Some contextualization happens with that tree of Lisp forms, and then it is evaluated within the context of an in-game device.
3. (Optional): If the program needs to communicate with another program on another in-game device, via in-game network, then some magic happens to determine where that program is, and runs it, too.

This is of course a lot more complicated than I’m making it sound, but it’s still far less complicated than in probably most, if not all, other mainstream languages. Lisp allows you, as a player, to run your own code within someone else’s online game. (And yes, we do run security checks on your code before we parse it. We’re not n00bs, thankyouverymuch.) This is not merely simulated. There are plenty of places within Spycursion where we “cheat” to make things easier on ourselves — hey, we’re an indie, cut us some slack — but Slang is not one of those places. Just thinking about trying to do all of this in C++ gives me an icky feeling. (I eagerly await the e-mail from someone telling me how you can do it in C++, if you just jump through these 27 hoops…)

So, yes, Lisp is awesome as a game server, but I have a feeling that’s not what most of you are here for. You want to know why we’re using Lisp for the Spycursion client, and how you can write your own amazing thing in Lisp too, and clearly the answers are because I’m insane and you should stop listening to me because it’s fun, dadgum it, and by being a masochist early adopter and maybe having a fairly simple game, graphically. Sarcasm aside, these questions deserve longer answers:

Why Lisp (for the client)? Okay, story time. Long, long ago, when the Spycursion server was just Slang and a WebSocket interface and not much else, I set about creating a text-only testing client. I did this in Python, figuring it would be relatively quick and easy, which it was. At this point I’d not completely decided on how the client would be implemented, but I reasoned that, despite Python not being my best language, it would be easy to find developers for — so I could handle doing all the server-side Lisp as long as I had someone else dedicated to the client.

But there was a problem: Writing in Python just wasn’t fun. Some of you may not understand this, but it’s a phenomenon I’ve heard about before — once you get “spoiled” by Lisp, you have trouble getting motivated to code in any other “lesser” language. This was before we existed as a studio, when I was doing this project entirely by myself, so I didn’t have anyone else to shove the Python work off to, but I knew it was important to get something visual produced so that I could begin to show people (not simply tell them) what Spycursion was about.

So I chucked the Python client, rewrote the thing in CL, and around that time, started getting ideas of what I felt this fledgling studio could be. In my opinion, the reasons “nobody programs in Lisp” mostly boil down to, well… because “nobody programs in Lisp.” The community is small, so there are few tools available, so the community doesn’t grow because people don’t use Lisp for major projects due to a lack of tools. This is even more true for Lisp games specifically, but I believe that this chicken-and-egg problem can be helped by creating a well-known game in Lisp, if only to point to it as a success and prove that it can be done. Additionally, by open-sourcing the client code (which we’ve not done yet, mostly due to legal questions that need answering), we show new and aspiring Lispers how it can be done. Again, to avoid getting ahead of ourselves — this thing could still fail, perhaps in spectacular fashion. But at least if it does, you’ll get a front-row seat. 😉 And I guarantee you that it won’t be because of the programming language we chose.

Why do you think it will work? As I mentioned before, Spycursion is weird. There are very experienced people within the Lisp community who think that Lisp, in its current state, is not ready for serious game programming. I have no basis on which to disagree with them, but I do think it depends on the type of game you’re creating. Spycursion has several things going for it that make it different from what you might imagine as a “typical game,” especially a AAA game:

  • There’s no twitch action. An ill-timed garbage collection isn’t going to be the difference between life and death. As of yet, we’ve made no attempt to customize GC or really push for low-level performance in ways that might be challenging to do in Lisp. We might, at some point, but I’m guessing we won’t even need to.
  • Much of the tricky stuff is offloaded to the server. Don’t underestimate the advantage of having a server (read: one single platform, of your choice) running parts of your game. That means fewer shared library headaches and fewer client performance woes — assuming you do everything asynchronously — for starters. (Oh, but please don’t be that developer who forces a network connection for your single-player game. That’s just rude.)
  • We don’t need to build for consoles. Ever tried to run Lisp on the Switch? I haven’t… and I don’t want to.
  • Physics? We don’t need no stinkin’ physics. Or at least no physics that can’t be calculated based solely on what I remember from 9th grade Geometry.
  • We keep graphics simple. I don’t really know how to quantify that, but the game is meant to be played 3rd-person, from a distanced zoom level. (We let you zoom in, but I wouldn’t necessarily recommend it.) The assets will be relatively low-poly and there will be relatively few of them. Note that “simple” does not mean ugly. We’re aiming to make it all look good while still putting most of our effort into gameplay — graphics are one of the places we “cheat.” You’ll be able to judge how we’re doing once we finish the Kickstarter trailer.

Put all of the above together, and you get a picture of a fairly minimalistic game client that really gets out of the way and lets you enjoy playing. (Or at least that’s the picture I hope you get!) And to be clear, I am not saying that fancier, AAA-level games can’t be made with Lisp. I’m saying I really don’t know, but this is our attempt to get as close as we can with the resources we have.

How are you doing it? I would say “pain, sweat, and toil,” but that kind of describes all game development, so…

  • The engine. Oh, just kidding, we aren’t using one. In 2018, I know of at least three Common Lisp 3D game engines in varying stages of development: First Light, Trial, and cl-bodge. In 2017, when I was researching these engines, they were all either too early in development or otherwise just didn’t fit our needs. They might now, but I haven’t followed their progress enough to know for sure. This brings me to what is maybe the most important thing to know if you’re looking to write a non-trivial Lisp game in 2018: You have to be okay with writing a lot of things yourself. Lisp makes this fun to do, and might still even save you time overall depending on just how much you need to write. But it’s a very different mindset from being, say, a plug-and-play JavaScript developer.
  • CEPL. CEPL is an abstraction layer around OpenGL which has been a joy to work with, once I figured out how. (Tip: See the author’s video stream, it’s great.) Its goal seems to be to make OpenGL lispy and fun to work with, and I really think it has achieved that. Spycursion uses CEPL extensively, and while I’m sure we’re doing some things suboptimally, performance has been fine so far. We’re also using cepl.sdl2 which brings in cl-sdl2.
  • QTools. QTools is a lispy wrapper around Qt 4. Most games probably won’t want the heft of Qt, but our device UI actually needs something a bit more featureful, so it’s worth mentioning. We have run into some build problems with QTools, particularly on Linux. Add in that there doesn’t seem to be a Qt5 update on the horizon, and we may well end up switching away from it (to what, I can’t say yet). But it’s currently working well, for what we need it for.
  • Other libraries

And that’s it! Lisp game development isn’t for everyone, but I stand by my assertion that it can be done, and done well, given the right game — and perhaps the right amount of patience.

TL;DR:

  • Use CEPL. Or one of the engines, if they fit. Or maybe both.
  • Yes, you should do it, even if you fail. That’s how the community grows.
  • Be prepared to write a lot of stuff yourself. This is not necessarily a bad thing. It’s fun!
    • Except skeletal animation. Don’t write that yourself.
  • Support our Kickstarter starting on February 26th!



Suspicious Activity

Over the last several days, you may have noticed a handful of cryptic messages being posted to our website and various social media presences. We don’t know who (or what) is behind these strange postings, but rest assured we are working as quickly as possible to solve the mystery.

Additionally, we noticed some kind of analysis tool posted on this website. As of now, its purpose is unknown, but it seems to be looking for a 32-character string of hex characters (0-9 and A-F). For example, a string like this: 46b6726a8a327e007d41d9f603bae95d.

At the time of this writing, we’ve discovered eight of these strange messages and ciphers, but will let you know if we learn of more.



Post-PAX Plans: What’s Next?

PAX was an amazing experience for us and we’re incredibly happy with how it turned out. We want to thank everyone who got in involved, no matter how big or small your contribution. Even if you just retweeted one of our PAX tweets, you’ve helped us and that means a lot. We’re extremely grateful for your support.

What’s next for (defun games ()) and Spycursion you ask? Well, let’s run you through it.

Currently, we’re deep in development on a whole bunch of game developer stuff. Animations, bug squashing, camera code, etc. Nothing super exciting or announcement worthy just yet. We’ll be sure to update you on anything exciting!

We do have a few other things planned, though. Firstly, we’re getting ready to launch our Discord server. This will be a great place for people to discuss Spycursion, us, the weather, or whatever else strikes your fancy. More details on that coming soon.

Secondly, since our first puzzle event was such a success, we’re thinking of doing another! If you took part in the PAX West puzzle event a couple of weeks ago then stay tuned because we’ll have more to say about this soon. If you have any feedback about our last puzzle event, please don’t hesitate to hit us up on Twitter, email, or Reddit.

And, of course, we are continuing to plan the various aspects of our Kickstarter campaign. We want it to be as good as it can possibly be so don’t hold your breath for a launch date just yet. It’ll begin when it’s ready and when we’re ready.

Join the Team

As always, we’re looking for lovely people to join our team and lend a hand. If you, or someone you know, is into the idea of Spycursion and has some expertise in software development, particularly experience with Common Lisp or a Lisp-like language, then get in touch. We’re extremely passionate about Spycursion and, like you, we want to see it come to life as soon as possible. A little help on the development side will allow us to bring that dream closer.

We’d love to hear from you! For more information, see here.