• 2017-05-15T00:10:00Z Fix various broken links.

See The game jam page for context.

My experience

I decided this year after having hung out in #lispgames and piddled around with trying (mostly unsuccessfully) to learn OpenGL for a couple months to actually build something for the first #lispgames (a channel on Freenode IRC) game jam.

This was overall a pleasant experience, I learned a lot and ended up making a game that you can find on my gitlab. I consider this game to be a spiritual prequel to my eventual large game project in a lot of ways, since the theme is similar but the scope massively small. I had a lot of fun and learned a lot of things, and I plan on writing about them here in length, but i'll start with the post mortem template given by the game jam organizers.

What dialect/tools/libraries did you use?

I used Common Lisp. I programmed in Emacs/SLY (not slime, and also not the scheme engine sly) and used a C terminal (with corresponding wrapper I put together) called BearLibTerminal. The wrapper I wrote can be found at gitlab. I used cl-autowrap and c2ffi to make this wrapper. For the actual game I also used axion's crawler for dungeon generation and split-sequence, alexandria, and cl-heap as supporting utility libraries. Finally I use quicklisp of course to get the libraries and SBCL as my development Lisp implementation. I also tested on CCL and tried (but failed) to test on Clisp.

What sort of game did you choose to make, and why?

I chose to make a small necromancer themed roguelike. The main reason for this was that I was able to get away with using BearLibTerminal due to the minimal graphics requirements and therefore could avoid trying to learn OpenGL during the jam (since I still haven't learned it properly). The secondary reason is that it is a nice prototype for some of my concepts about my forever project game.

What went right, what were some successes?

BearLibTerminal worked out great, besides some problems people are having currently getting it to work on their machines. It was easy to work with, I didn't run into any bugs, and it mostly stayed out of the way. Using Common Lisp worked out great as well, I strongly enjoyed my first real experience with CLOS and mixing it with functional programming and while I didn't always take proper advantage the REPL driven development worked out great. I thought overall the vision came together decently as well, though not perfectly.

What went wrong?

A few things. First off, as expected, even with my vastly downsized requirements I ended up having to drop features in order to get it done. This means I ended up with a pretty bare bones/boring game, but a working one. While I already "knew" this, I found concrete evidence that making a game fun can be hard. I don't think the game is currently fun, despite all the effort put into it. It largely feels incomplete, too simple.

Another thing that I wanted to do but didn't get done was adding unit and property tests to the game. I still plan on doing this post jam, but so far there are absolutely no tests.

Finally the code quality was tremendously awful. It is all one file and not organized at all, and a large part of that is due to feeling rushed. I should have planned my time usage better and made less excuses about how it was fine to write bad code now cause I could rewrite it after the jam. It bit me more than once during the jam, and I had to refactor things to get them to work at all.

Overall I feel the biggest things that went wrong were overestimating my motivation and underestimating difficultly of things.

What did you learn?

I learned CLOS is a joy to work with, and a ton of specific things about it.

I learned about Dijkstra maps and all the cool things you can do with them. I also learned all over again how sometimes I can just get a mental block on something and then have it just suddenly click (in this case how to flood fill the map with dijkstra map data).

I learned to restart my lisp image often, because otherwise you can/will have lingering bugs that you don't know exist (this bit me only once, luckily).

I learned that the simple things in AI can be both surprisingly hard and simple.

I learned that feeling rushed is not overly good for code quality (I already knew this, but it was reinforced.)

Finally I learned once again that I tend to overestimate my motivation and drive to complete a project.

What did Lisp enable you to do well in this entry?

A big thing was that the little motivation I did have to work on this largely came from getting to work with Lisp. Otherwise I probably would have just dropped out of the jam. Besides that I'm not sure that it really gave me many specific advantages, as I didn't really use the language to its full potential. However, I feel the ability to use CLOS + functional programming was very beneficial as well as the ease of REPL driven development (especially since I ended up not writing tests) and the general dynamic nature of lisp.

What challenges did Lisp present in making your entry happen?

Truthfully, not many and none major. I am still relatively unfamiliar with the language so I had some growing pains while learning, but #lisp and #lispgames were very helpful with those. I'd say most challenges were just due to my ignorance more than with the language itself. I even started getting used to the debugger after all the errors I caused!

How long have you used lisp and what previous gamedev experience do you have?

I have used lisp really for only a couple to few months. I have played with it as long as two years ago but haven't really ever written anything complete until recently.

In a similar vein, I have never completed a game of my own design before. I have gone through a few books that guided you through creating games, mostly in my youth, but never done my own idea from start to finish.

Conclusion

Overall this game jam was definitely a positive event. I learned a lot, got some good practice with Common Lisp, and even got something to show off (even with the awful state of its code). Definitely a win for me.

Another exciting thing was getting to see the other entries in the jam, I highly recommend checking them out. They are great. I'm pretty sure all of the games were more complete/fun than mine too!

I'm am looking forward to the next game jam, hopefully in a few months.

• 2017-05-15T00:10:00Z Fix various broken links.

Origin

I have a game idea. More importantly for a young programmer, I have a project idea. What's more, I have a Forever Project idea.

This idea has been building in my head for quite awhile, but it is only the past few weeks that it has begun to coalesce into something I can work toward. I have decided to put down my rough thoughts on this project.

Since I have been old enough, I have played video games. Yes, I'm young enough that it wasn't since video games were mainstream but rather since I was old enough. They are my obsession and addiction, even more so than programming has ever been. I enjoy the control, the complexity, the predictable outcomes, the escape from reality. The biggest key for me though appears to be that second one: Complexity. I seem to thrive on it, though I have hit my limit occasionally(story for another day). One of my favorite games is Dwarf Fortress and it is indeed one of the most (not THE most) complex games that I currently know of existing. It has a strong influence on my own game idea. It is the work Tarn and Zach Adams and started the infancy of its development in 2002 and is not yet complete. The year of me writing this being 2015, you may understand why I have decided that my game idea, heavily influenced by Dwarf Fortress and its complexity, is a Forever Project.

Early Decisions

One of the things about Forever Projects is that to be a proper one you have to really be doing what you want to do, not what you think will work or what other people want you to do. To that end, I do have some most likely unpopular set-in-stone(at least for the beginning) decisions on this project.

• It will be in Common Lisp, at least the primary portion. I plan on the project being very modular.
• All primary pieces of the application code will be licensed under the AGPL. Supporting libraries developed in the course of the project will be under a more permissive license.
• It will be open source and available from the first commit (on my gitlab to start with) and I will invite other programmers to help and/or fork as early in the development process as they wish.

You may notice all these(there are so many!) early decisions are technical, but I am a programmer after all. I tend to focus on the technical details first. Pretty much everything else is still very ephemeral and open to change. Another thing about these decisions is they make it rather hard to make a traditional business around the game. That's okay though, because if I ever even get to something worthy of calling a 1.0 it will be a grand accomplishment. Money is not everything, after all.

What's the game idea already?

Keeping in mind this is in such early stages that most people would not even be writing about it, I'll go into the game idea here. The basic idea is I want an Undead-focused Dwarf Fortress like game with a heavier focus on RPG elements. I say Dwarf Fortress like because it is probably the game that is the closest to what I want, but already the idea is diverging in rather key ways from Dwarf Fortress. I first considered making a Dwarf Fortress mod but quickly decided that would not suffice. I highly doubt i'm the first person to come up with an idea like this, but AFAIK such a game does not yet exist. If I post this and someone points to a game that does this, I will be kind of sad and have to come up with a new forever project while playing it.

Below is a bulleted list of random thoughts about this game, from a design standpoint. Many of them reference Dwarf Fortress for now, though I'll have more fleshed out versions that stand on their own before I publish an actual goal list to the game repository.

• Fantasy. Human, Elves, Orcs, Goblins, Dwarves. Perhaps more races.
• Many other types of magic besides necromancy is likely, though probably not for the player (unless the game branches out to other controllable factions)
• Procedurally generated world with history, almost identical to dwarf fortress in this respect.
• Undead replace dwarves as the primary workforce in the game.
• Necromancers replace/augment the nobles concept from Dwarf Fortress, you start the game as one.
• Something similar to Battlezone/Battlezone II style control (see https://en.wikipedia.org/wiki/Battlezone_%281998_video_game%29 and https://en.wikipedia.org/wiki/Battlezone_II:_Combat_Commander) [big departure from Dwarf Fortress here]. Not the fps style so much, but the in-person + RTS combination. More RPG + RTS than FPS + RTS.
• Starting graphics will be ASCII and/or simple sprite 2d graphics similar to Dwarf Fortress. Mainly because 3D is hard and I have no art skills.
• Undead will have to not be a nigh-unstoppable horde like in Dwarf Fortress. Early undead will need to be pretty brittle and weak for balance.
• Some kind of finite resource will be required to maintain undead, for balance/difficulty purposes. Blood/magic energy/brains/weird nutrient all considered as options so far.
• You'll also have to provide food, drink, and sleeping areas for yourself/your living people.
• Corpses required for more undead. Pillaging likely will be a necessary part of the game. Possibly automated (Hey you, go out there with 10 undead and bring back some fresh corpses).
• Living disciples will migrate to your base.
• Killing living disciples (willing on their part or not) when in need of more undead will be a thing.
• More independent types of undead (Vampires for one probably) with less direct control(if any, maybe vampires are rivals?) given should exist.
• Possibly more direct control than dwarf fortress over the minions, but no direct control over your living disciples/more independent undead. Some kind of limit to force you to delegate will be necessary here.
• Less focused on digging, very possible that some geologic realism will be sacrificed when compared to dwarf fortress. Though, with it as a guideline perhaps it won't be necessary.
• Lose condition will be you(your starting necromancer) dying in such a way that you lose control(becoming a Lich or other sentient undead is fair game). In the "end-game"(win condition not planned) you will likely be a powerful undead emperor/empress of some form or another.
• RPG elements for your main character. Multiple immortality paths likely.
• Building will be done through a combination of brute force from undead minions + magic(magic might replace Dwarf Fortress architecture skill).
• Manufacturing is similar to Dwarf Fortress, forging/making items are going to be a must.
• Possible trade with other undead bases and/or more unsavory types from the other races? This could open up the path to a mostly economic undead game.
• Possible tribute negotiations. You give me your dead every month, we give you protection/trade.
• Main character moving about in the world (like Dwarf Fortress adventure mode) will be a necessity. Keeping main character but starting a new base (maybe when fleeing enemies?) would be possible.

Technical Ideas

Here is where I'm most excited. In the spirit of a Forever Project, a primary goal of the project is to learn new things/try out ideas on a technical level. Here are a few of these more technical ideas.

• Portable. Ideally I'd like clients and servers to run on Mac, Linux, and Windows. Clients should be relatively easy on mobile too, servers probably won't ever be attempted on mobile. Since I chose common lisp for the server, this will be far from a given I believe. To start out i'll only be making it work on Linux, but while keeping an eye toward cross compatibility. This is not a hard requirement, I would consider having the server be Linux only but clients be true cross-platform.
• Client/server architecture with multiple heterogeneous(different engines, different machines, different communication mediums) clients connected as the same player possible. All can control/view the game independently and concurrently. [This is a huge huge task requiring lots of learning on my part, and even more effort!]
• If I manage the above, multiplayer should be a good way towards being implemented so that would be an option. I do not consider multiplayer a priority.
• Speaking of heterogeneous clients, one of the reasons I wanted this is so someone can say "I want a 3D OpenGL client" and I can say "Sure, go make it. Here's the server spec. Talk to the server and do whatever you want to display the data you get back.". Another cool theory is multiple perspectives of the same game in multiple windows/monitors. It's possible that one client is better for one in-game task than another. This would allow you to switch to gain their strengths. View-only perspectives should also be possible with this setup, for a dedicated streaming client or something like that.
• The above would also be able to avoid ugly hacks like Dwarf Therapist where it has to read the memory of the game directly in order to get information.
• Strong multi-core/multi-processor support. Especially on server side, as that should be where most of the heavy lifting is.
• Smart AIs with deferred processing to other threads/processes(/machines?) for complex decisions. While I know little about it, I love the ideas of AI programming and this would be an opportunity to learn it in my own sandbox. I'm specifically interested in gaining efficient use of concurrency while still interacting with the game fast enough.
• Possible server to server communication. This could allow a form of multiplayer (or even singleplayer) communication between games where in-game it is considered some kind of dimensional portal or something. Open possibility of raiding other servers for resources once you use up your world's resources (if that's possible, may not be).
• Extensive server-side mod support. I think it will be "Fun!"(see http://dwarffortresswiki.org/index.php/DF2014:Losing for what I mean) to learn how to make it possible to support crazy mods of the game while still having good performance and all the other things above. A possible goal would be to have the ability to completely re-theme(i.e. to sci-fi) to game though that might be too lofty.

Things I'd learn if I did everything in this forever project

• How not to sleep or have a life besides one project.
• Pretty advanced AI concepts.
• Graphical programming with multiple APIs/Platforms.
• Client-Server syncing with a real time loop.
• Network latency optimization
• How to master debugging
• How to write game lore
• How to balance a game
• Just how hard game programming and design really is (hint: hard)

Immediate path forward

• Finish my current small side project so I don't feel guilty starting a new one.
• Learn a lot more common lisp through various means including project spikes and books.
• Learn AI programming starting with "Paradigms of AI Programming" and moving from there. This will require toy programs/books.
• Concurrently with the above, play around with the basic framework for the server <-> client communication + splitting the server into multiple processes (So figure out basic IPC for one)
• Continue brainstorming gameplay ideas. It isn't near fleshed out enough so far.
• Write more blog posts about all of the above.

• 2015-10-21T09:21:00Z Updated published/updated timestamp to be iso8601 format.
• 2017-05-15T00:10:00Z Fix various broken links.

After many years of my domain leading to an "Under Construction" page, I decided that it was time for me to actually sit down and write a website. I decided I wanted to use Clojure since it was my new favorite language to play with and started down my usual route of a MVC based site. As I played with Compojure and Korma I realized that for a simple blog/portfolio based site MVC was overkill.

I scrapped my original idea and researched static site generation in Clojure. I quickly found a blog post by Christian Johansen on using Stasis and other Clojure libraries (see this site's gitlab for a full list[no longer accurate since site has been rebuilt]) to setup a basic static site with a developer server.

However, this basic template was not complete enough for my site as-is. Primarily, I needed more dynamic control over the site layout/templating. For instance I wanted the site title to be generated based on a formatted version of the file name of the page. The formatting itself was easily accomplished:

(defn format-title [title]
  (str/join " "
            (map str/capitalize
                 (str/split
                  (str/replace title #"(.*/|\.html)" "")
                  #"_"))))

I did find myself with a small problem. I ended up needing to map over a hash-map and format the key then pass the formatted key to a function along with the value. I didn't find a function that already does this, so I imagine there was a different way to do it. In the end, I ended up with this function to perform this:

;; This is probably a case of me not knowing a better way to do this...
;; my-map is a hash-map
;; key-func takes a key and returns a key
;; val-func takes the formatted key and the val and returns a key
(defn map-map-with-funcs [key-func val-func my-map]
  (apply merge (map (fn [[k v]]
                      (let [new-key (key-func k)]
                        (hash-map new-key (val-func new-key v))))
                    my-map)))

I ended up using this function like this, where pages is a hash-map with the key being the filename and the value being the contents of the file:

(defn partial-pages [pages]
  (map-map-with-funcs #(str/replace % #"\.clj$" "")
                      #(fn [req]
                         (layout-page req %1 (load-string %2)))
                      pages))

I am new to clojure so I imagine this is neither idomatic nor efficient (for instance, my map-map-with-funcs function may be better written as a macro). However, it is certainly working for my purposes.

The best part of all of this is that in the end, what I have is a bunch of minimized html/css/js that is easily served by Nginx making a very low resource site that easily runs on my small Linode instance. I also got some practice using Clojure.

My next steps are to include some kind of hosted comments (I need to research options) so that I can get feedback from the readers of the site and continue to write blog posts (and talk at local meetups).