So, here I am absolutely jamming it out in LÖVE. For the uninitiated, love is a wonderful little framework for developing games. It's essentially a lua wrapper for SDL with some additional bells and whistles. It's small enough that you can learn the most important stuff (which is most of the framework) in a few days, but powerful enough so that you can create some impressive shit with it. There are some things that are painful to do (exporting to ANYTHING) but the actual sitting and writing code bit is very pleasant.

Enough nerd talk.

Lua library management (it is exactly as boring as it sounds)

I'm working on a tiny story game about robbing a governmental agency for various reasons. I would like to write the story in a format that's a bit nicer than just bashing shit into an array, and there are a bunch of lua implementations of Ink (a narrative scripting language), so I dug one up, dropped it and tried to make it run. My screen flashes with errors. Damn it.

Right, lua has static filepaths, so the library has to be put in the same location as the developer had it relative to the root of the project. Fine, I move the library folder to the root of the project. A new error flashes. Shit.

I bash at it for three more hours, and after changing to a different library as well as bashing at that for a bit it actually starts working. It is 23:34 and I feel pretty fuckin exhausted. This has not been fun. I am not enjoying this.

When it comes to writing libraries, Lua has some serious issues. A minor one is that by default require paths are based on the root of the project instead of being relative. A major is that Lua runs in a lot of different environments. Basically, if your code uses runtime specific (shit that only exists in engine X, but you are running engine Y) functions then you will have to port the library before using it. Pain. Suffering. Agony.

So my opinion of lua has shifted, from being "this would be the wonder for gamedev" to "this is wonderful for gamedev, but not for managing dependencies".

The pleasures of Pico-8

I recall a talk that Joseph White (the Creator of Pico-8) held in which he talks about creating cozy design spaces. Basically, a space in which you just vibe out games. That is a very good description of how pico feels to use, it's really hard to not have fun (or in the very least feel like you are solving actually interesting problems rather than trying to make code that randomly fails work on your machine).

Pico has a quite harsh limit on the amount of code that you can write. Without going into specifics, you generally have to stop after you've spent a gamejam amount of time on the game. Then you have to ship the game, or start chopping out features, alternatively write shorter code. This means that importing a 700 lines long library is completely out of the question, it just won't fit.

In pico the largest "library" I've used is probably an approximation of a distance function, which is 5 lines tops. The rest of it? Written it myself. The particle system? Mine. The dialogue system? Mine. The outline creation thingy? Also mine. In pico you just write so much more yourself, and it's a really fun way to work. You also learn a lot more, since you can't just require("solution"), you actually have to design and write on your own.

Why not just use pico if you love it so much?

Pico is wonderful for small, isolated projects. However, I want to develop games that have a resolution other than 128x128, and I want to be able to change the color palette. For the projects that I'd like to do, pico is often too limiting for me to actually do them. I'd also like to be able to barf out code without having to resort to hacky solutions to make it fit in the cart.

And while picotron (picos really damn ripped sister project) is in development is looking really promising, it doesn't let me import my own wavs, and it's also quite unstable still. Pico in general also seems to be targeted really heavily towards pretty pure programmers, and I really want to be able to do crazy things with the music and art as well as the code and design.

Writing my own damn lunchbox

I would like to use the inky editor, tiled, fmod and all those fancy thingies. I do however think that I will enjoy the actual process of making games a lot less if I work with those tools instead of rolling my own. Part of that is that when I add complexity to the tools, I feel like I actually have to use that complexity. And if I've learnt anything from software development, it's that more complexity is generally just a pain the fucking ass. Simple but effective is good. Don't try to do everything, do a few things really well. You get the point.

When I write my own tools, I actually make progress, instead of whining "this doesn't import json, I have to convert it with a another library, why are there three libraries now? four? oh god please end me" I just make the damn thing and then I work with it. Complexity is really a creativity killer for me. The more toys I have to play with, the less I seem to actually enjoy playing.

Writing the tools forces me to keep them relatively simple, but I can in exchange get really flexible with them. A dialogue system where you can clear the screen instead of displaying a line? Implemented in five minutes. Doing that with the inky editor? Hang on, let me read the manual and mangle it for two hours. There is also the benefit of being able to make the tool fit for the exact project I'm making. And having a really intimate knowledge of the tool. I know how it works, how it doesn't work, how to mod it and so on.

I'm being kind of silly here

I don't want to import lua libraries, I feel like it'll be more fun to write them on my own, fuck you. This is not the most efficient way to make games, but I'd rather have fun and actually finish things than spend time trying to make external tools work, get upset and then never continuing the project. When it's just me and my code, it all works pretty well.

There is also a limit to what I think is sane to write on my own. I'm not planning on writing my own DAW, or image editor. That would take a lot of time, and I don't have to do a lot of work to make the engine and the image editor work together. I just import the damn png. Maybe the real lesson is to only use data formats that are widely supported. I'm not entirely sure to be honest.

All that said

So, if the people who developed the original doom game wrote their own level editor, and I can bash out my own tools in pico, then I should be able to do that in love as well. So from now on, I'll be very restrictive of adding other peoples code into my project. No damn glue code for external editors either. Maybe I'll make an exception for Tiled, but probably not.

And if you think about it, you get better (and faster!) at the things you practice. If I practice wrangling libs, I'll get better at that. If I practice writing games in love, I'll get better at that. That's something to think about.

This has been a rant. Thank you for listening. Games will come.