It’s been about a month since our Kickstarter campaign ended and we launched our Patreon page. As people who have watched exciting projects rise and fall — often without even saying goodbye — the last thing we want is to leave Spycursion dormant for months while our fans wonder what happened to it and if we will ever return. (If Spycursion ever does fall into the bit bucket of history, it won’t be because we ghosted you — it will be because we went out in a blaze of glory.) To that end, our goal is to share a progress update roughly once every month, even in months where not a whole lot has happened…
… like this one! As I hinted in the last post, both Mauricio and I have had to “take some time off” to focus on useless trivialities like, say, paying the electric bill. Aside from that, we’ve been zooming out a bit to discuss the Spycursion architecture and how to tackle a development roadmap in our new post-Kickstarter world.
Ooh, Shiny!
Can I be honest? You know all those parts of the game that you’ve probably seen from our trailer? Those are my least favorite parts. The parts of Spycursion that I enjoy talking about and sharing the most are, well… the parts you can’t see. There are good reasons for that. Spycursion was never meant to be a graphics-first game, and in fact, I hadn’t even planned on making it 3D! My original vision of Spycursion was as a 2D isometric world. It evolved into 3D throughout the process of development and commissioning assets, as we decided that 3D would allow for greater flexibility in terms of feature additions and look-and-feel modifications.
But really, we should go back even further. In July 2018, we published this post containing the very first public Spycursion screenshots (with the exception of this very, very early device UI screenshot, in Nov. 2017). At that point, the game had been in development for nearly a year. We hadn’t shared screenshots because we weren’t focused on anything that could be screenshotted. Then, we read pieces from some wise(?) internet denizens who told us that, in order to have a successful Kickstarter campaign, we would have to make shiny things and show them off and generally become glued to social media. (Anyone who’s ever worked on an indie game knows where this is going.)
Hence, our focus shifted from server to client, and more or less remained there until the Kickstarter launch. I don’t know whether this was ultimately the right decision, but I do know that not focusing on the client certainly wouldn’t have helped that campaign. In any event, I personally feel that the visuals in Spycursion’s trailer turned out well, but not as well as they could have. There was a degree of crunch in the weeks and months leading up to February, and as a result I didn’t feel we were able to give the client the polish it deserves. That’s why one of our first post-Kickstarter discussions was about…
(Shiny) Client Architecture
If you’ve followed our blog, you know that the Spycursion client relies heavily on a couple of Common Lisp frameworks — CEPL and QTools. What you might not realize is that, within our code base, these two frameworks never even touch each other. It’s almost as if we have two separate clients that just happen to have the same name. That makes some sense, of course, because they have very different purposes. But let’s say that we want to display a device UI (a Qt QMDIArea, if you’re fancy) partially overlaid on top of that 3D world, rather than in a completely separate window. I’m not sure there’s a good solution to that. (QtOpenGL comes the closest, but we dismissed that because it would be difficult to use with CEPL or other GL frameworks, plus it had some problems on OS X.) Qt also adds some bloat that we’d rather not have.
Though we’ve discussed it before, without the time pressure of Kickstarter, we’ve decided to begin replacing QTools now. And that replacement will be… Nuklear! Why Nuklear? Well, for starters, look at these two screenshots and tell me which one fits better in a game about cyberespionage. (Yeah, I thought so.) In seriousness, what’s attractive about Nuklear is that it’s simple and embeddable, and doesn’t try to take over your entire application.
Now, the astute and tech-savvy reader may be thinking, “Wait, Nuklear is written in C, not Lisp… does it have any Lisp bindings?” Well, yes, yes it does! We’ve decided to give cl-bodge a shot, specifically the UI module, and see if we can make a workable device UI out of it. Another potential benefit here is that we could get away from traditional desktop UI paradigms of the sort enforced by Qt, and design something more unique. It’s too early to know what that might look like, but I’m excited about the possibility.
If cl-bodge works well for us on the UI, we may also use other modules of it for other purposes. It is possible that we will eventually replace CEPL, but I think the more likely outcome is that we blend the two, taking advantage of cl-bodge where it makes sense and working with CEPL as a friendlier alternative to raw OpenGL (cl-opengl).
More Shiny?
Between paying the bills and replacing QTools (not to mention me having a strong desire to hide back in my server code), it may be awhile before we can share more screenshots of any quality. It will definitely be awhile before we share more videos. When we do, we’ll try to include some upgrades to the 3D world, as well. We picked up a fair amount of technical debt during pre-Kickstarter crunch time, so performance improvements are definitely in order. With performance improvements, we can add more “bling bling” (to use the words of an influencer who didn’t want to share Spycursion because it didn’t have enough of that). And if we get enough funds through Patreon, we could add new 3D art as well.
What Kind of Shiny Would You Like to See?
As always, we invite our Patrons and followers to help shape not only Spycursion itself, but how we share it with you. What do you think about the technical changes outlined above? What do you want to read about in future updates? What would you like to see on our Patreon page?