Category: Rants

A few weeks ago I did a writeup on Limbus Company. You can read it here.

After playing more, I’ve realized there are a few factual things I got wrong in my writeup, and also a few more things I wanted to talk about. So I’ve decided to put those here.

Some Corrections

I had complained about Limbus Company’s energy system, Enkephalin. I thought that if I lost while playing, and had spent energy or modules to attempt a level, I would just lose that energy.

As it turns out, in many cases, the whole amount of energy is refunded if you lose. And in others, even though there is some loss of energy, it’s 5%. So if you spend 20 energy to enter a stage and lose, you get 19 back.

I still don’t like energy systems in games. Energy systems are in my mind, a gaming dark pattern. But Limbus Company’s energy system isn’t as bad as I thought in my initial writeup.

Glorified slot machines, and some other F2P bullshit

I never really mentioned that Limbus Company does have a Gacha system. In abstract, it’s very similar to most Gacha systems. You spend premium currency, which you can buy with real money, or earn small amounts of per day. In exchange, you get random characters.

Mechanically, though, it’s actually somewhat unusual. For starters, the game starts the players with 13 characters, and each extra “character” you get is just an alternate personality for one of those 13. There haven’t been any times when I’ve gone, “Wow, I need a character who can do X, I guess I need to spend the Gacha.”

The game also has a system for upgrading characters that boils down to: the default free characters get stronger easier, while premium characters are resource sinks.

Again, I don’t like Gacha systems. But there was never a point playing Limbus Company that made me think “I could beat this if I just spent money.” It’s a better system. Admittedly, it’s better in the same way that being stung by one wasp is better than being stung by five.

Going back to actual gameplay: Limbus Company does have a solid combat system, but it’s incredibly poorly explained and displayed, and the more I play, the more convinced I am that the tutorial was some sort of joke.

So yeah, Limbus Company. An interesting F2P game with generally reasonable systems by F2P standards, and absolutely stunning lack of meaningful tutorials.

Ludum Dare 53 was this weekend, and I participated for the first time. For those who haven’t heard of Ludum Dare, it’s a game jam where participants can work with a team to make a game from scratch in a limited period of time. You can read more about it on the site, but I mostly want to talk about my experience, and some lessons learned.

First up though, let’s talk about the game I worked on. This event’s theme was “Delivery.” So I worked with my friends to create Demon Lord’s Catboy Pizza Delivery Service. Here’s a link to a playable version on itch.io.

My contributions were in three main areas, and those are the ones I’ll be focusing on for this retrospective.

Art

I did the art for the monsters you deliver pizza to, and also the hub zone, and the enemies. These were a lot of fun to draw. But we used a default tile set, and my art sticks out and doesn’t quite mesh with it. That said, they did get some positive feedback, so I’m glad people enjoyed looking at them.

I think there are two key things to recognize here. First off, I didn’t have a workflow set up to build pixel art, which meant my stuff didn’t match our pixel art tileset. Honestly, have no experience in pixel art at all.

Second, I want to keep improving my art to match themes and tones. I want to improve my abilities around color and palettes. I don’t have any plans of becoming a professional artist in the immediate future, so this will likely remain a hobby, but I want to provide stronger and more consistent art for the next time I do one of these with friends.

I also want to create more compelling and entertaining splash screens and covers, because I think that would drive more engagement. Right now our main screen and splash is fairly dull. It’s a small thing, but I think it’s important for getting more plays and feedback.

Background Swapping

The only system I wrote any large amount of code for was the background handling. My code dynamically swaps the background art based on hitting flags in the environment.

It was also an excellent demonstration to me that I haven’t written any code for a long time. My professional job is technical, but mostly demands a very specific non-code knowledge, along with a broad smattering of other technical knowledge. (Database structures, query languages, various endpoints)

Point being, if I need to actually design systems, I freeze up a bit. For the next jam, I think I need to prepare by writing more code and practicing in Godot prior to the event to have the knowledge base to contribute more effectively.

That said, I am happy that I just asked my friends how to do things instead of sitting and suffering and reading docs for hours. So at least my ability to prioritize in tight deadlines has improved slightly.

Level and World Design

I built out the world and level that’s present in the final game, as well as handled most of the enemy placement. There are two groups of lessons here for me: first the ones related to Godot itself, and second the ones related to just better game design practice.

First, Godot as a tool: we decided early on to do a single large world with multiple objectives. In retrospect, this may have been a mistake. Because of how Godot handles scene objects, this meant that having two people with branched copies of our full_world scene would need to resolve merge conflicts, and only one person in our team had the background knowledge of Godot to handle that.

The end result was a scramble of rebasing and not touching that scene to avoid those conflicts, and it sort of rushed things a bit near the end.

The second is the world design itself. I think there’s a lot of room for improvement in the world design, on multiple points. First up, navigation and linearity. DLCBPDS had a large open world, and the player starts right in the middle of it. The player is asked to select a quadrant of the world map, and then travel to a goal within that quadrant. The thing is, in order to keep people from getting too lost, each of the quadrants is separate from the others.

However, in playtests, I routinely saw players go into the wrong zone almost immediately, after which they would have to backtrack the entire way when they realized what happened. Or more often, after I told them.

Simply put, this was a bad design pattern on my part. It made it too easy to get lost, punished getting lost with a painful backtrack. If I was to build this again, I’d want to focus on a linear path, or adding more in-world indicators to really hammer home where the player is supposed to go.

The bigger issue, and the one I need to think about a bit more is level design in games in general. I came into this jam with an intention to make things “Fun.” While I do think the game succeeded in being fun, I’m not sure the fun arose from the world the player navigated. There are some sections people enjoyed, specifically the areas I have mentally labeled “Pit” and “Tower.” But this wasn’t the result of careful design on my part, and more due to trial and error of design. I threw a bunch of different patterns at the wall and saw what stuck.

There were four patterns I threw at the wall, and I want to talk about them briefly. Pit was a large hole that you climb down. Tower was a large hole you climb up. Dungeon was a series of caves with some enemies, and Outskirts was a large empty void I filled with rectangles.

Tower and Pit were the most popular from what I saw, and I think in that order. And that’s because they’re the areas where using the game’s core movement mechanics are the most enjoyable. These areas let the player use the grappling hook to pull themself up, use dash jumps and dodge around outcroppings as they plummet.

But I’d like it if I could make every area that enjoyable. For the next game jam, I think that means I need to study our intended core mechanics better prior to just building things, find the fun moments, and elaborate on them. At the same time, I’d also like to have a more exact understanding of those mechanics, for example exact jump height, exact dash distance. That sort of thing.

Other Bits

I have some other thoughts that aren’t specific to me, but I think are worth noting, and considering for next time.

Our file structure was kind of a mess. Agreeing beforehand on a general unified structure for objects would be a good idea, including things like locations for art assets.

Our coordination has room for improvement. There was a point early on where two people spent time working on the same thing, and someone’s work got thrown out. This was both a waste of time, and also felt shitty.

Repo structure. We tried to do a single main repo, with each person having a fork. This got abandoned almost immediately. I think a single repo that everyone pushes branches and requests to is the way to go for this project. Not as some sort of statement on version control, but because at least a few of us (me) are too incompetent with Git for much else to be worth it.

Builds. Our final build had issues, including crashing on scene changes in certain versions for no clear reason. We needed to build earlier, identify these sorts of things earlier, and either mitigate or be aware of them before there were only two hours left to turn in.

Controls and tutorials. If literally nothing else, we needed to include a tutorial level of some sort. Plastering the controls on every screen we could AND the pause menu wasn’t enough. It was really stupid of me to think that people would just naturally experiment and find the controls.

Conclusion

For a first time jam, I’m actually super proud. We made something, it has at least some fun moments. I wish my contribution was a bit higher effort, but I’m glad it was there at all to be honest. That said, there’s a lot of room for improvement and learning.

I’d also like to thank the folks I worked with for putting up with me and inviting me. It was really fun working with them. Kalloc and Slabity don’t have things I can shill. But Meptl has done some cool stuff, so I’m going to link that here.

• Made an entire music video and documented the process for their favorite VTuber duo.

So if you’d like to see some neat stuff, maybe check their projects out.

More game reviews at some point in the future, I promise. But most of my weekend was spent making games instead of playing them.

This rant is a response to this opinion piece in the New York Times. You can read it if you want context, but your life is likely richer for not doing so.

In his piece “AI spells trouble for creatives — about time too” James Marriott includes a quote from Daisy Christodoulou: “ChatGPT sometimes produces superficially plausible essays that fall apart under closer scrutiny. But plenty of humans write essays like that too. In fact, it is one of the criticisms of PPE graduates.”

There’s something ironic in including a quote about things being superficial and falling apart under scrutiny, in an article that feels incredibly superficial, and falls apart under scrutiny. I’d quote more of his article in this response, but that means more people might have the misfortune of reading his 8 disconnected and unclear paragraphs.

Because I’m not James Marriott, and I value the time of people who read my pieces, let me offer my quick conclusion:

Mr. Marriott, you do not have a problem with artists or “creatives.”Nor do your lawyer friends, who have people roll their eyes at them, or ignore them at parties. You have a problem with assholes.

The fact that every artist you’ve ever met fits this profile does say something about the company you’ve chosen to keep.

Anyway, let’s get back to your opinion piece. I’m not 100% sure what your opinion is, which is bad, given that I’ve read your article 7 or so times now. Perhaps it’s that “Artists are a bit too full of themselves, and need to be taken down a peg.” Have I got that right? Have I summarized in one sentence what took you eight paragraphs?

Of course, you’re a professional journalist, and I’m not. Actually, my day job is working for a software company that sells what, at least on some level, amounts to automation software. This is likely why you were able to craft such a wonderful headline that grabbed hands, and filled those “creatives” you wish to see humbled with such rage.

James Marriott’s writeup addresses none of the actual issues many artists and writers have with the current generation of what I’ll lump as “content generation technologies.” He doesn’t talk about how their underlying training data may have been taken and used without compensation. He doesn’t cover how many of these models can be flawed backboxes. He just seem happy that this makes artist artists upset.

And so I must ask, Mr. Marriott, why? Why does it give you such glee that so many might be put out of work? Why is it, that when given space in a publication that more people read in a day than will read anything I ever write in my lifetime, you take that space to make perhaps the most petty argument that can be comprehended in favor of AI generated art and writing?

This is barely an opinion. It’s not even a rant. It’s a whiny self-centered hope that an emerging technology will “make some people who annoy me unhappy.”

I wanted to close this rant out by making some more ad hominem attacks, but unfortunately I can’t. You see, I can’t find any more of his work. When you google Mr. Marriott’s name, you find a comedy YouTuber/musician, with 2 million subscribers, and a few hundred thousand views on each video, and no other articles or writing by the one being ripped on in this article.