April 1 is Source Code Amnesty Day (it happened!)

Authoring
1

One of the most valuable resources for folks learning an authoring system is source code for existing games, so they can see how others have solved problems similar to the ones they’ve faced. Publicly-available source is also nice to have for folks who appreciate a game and want to learn more about the nuts and bolts of implementation, and it also helps satisfy the archival impulse that animates many parts of our community.

There are a bunch of great examples of public IF source code out there – I’m most familiar with Inform 7, where Emily Short and others have put out the source for big games with really clever mechanics, and of course pretty much all Twine code is public by virtue of the format. Still, there are far more games without release source code than games with it, and for many of the smaller authoring systems, there may only be a handful of worked examples out there.

The main reason for this is not exactly a mystery, of course – it’s the reason I haven’t released the source for my two games: the average author looks at the elegantly-conceived, deeply-commented stuff that the leading authors have put out, then looks at the regurgitated pile of dog sick that constitutes their barely-working game, and wonders what possible value there could be in inflicting such horrors on an unsuspecting public.

That’s all quite understandable. And yet, isn’t there something to be learned from an averagely-implemented game, or even a poorly-implemented one, just as much as from a well-crafted one? Isn’t it possible that creating a positive norm of releasing one’s source, regardless of the shape it’s in, would be an overall benefit for the community? Might it be the case that the current aura of shame many of us feel could be lifted if we realized that we’re all the metaphorically-naked emperor?

@mathbrush has been making this case for a while, and he’s convinced me: we have nothing to lose but our chains – and our perhaps-delusional attachment to things like “coherent coding practices”, “minimally-adequate commenting”, and “implementation that isn’t just a rapidly-collapsing tower of one-off special cases piled atop each other.”

That’s why I’m proposing that April 1 be denominated Source Code Amnesty Day: a day when we can all show our dirty laundry to the world, confident that if we all do it at once no one person’s awful awful coding will come in for special attention or derision. Marking it to April Fool’s Day also hopefully indicates the degree of seriousness with which folks should take proceedings.

To this end, I’m going to be publishing the source of the final releases of my two games on IFDB this April 1st, allowing myself an hour or so apiece to add some comments highlighting some of the biggest howlers and missteps. I hope it will be instructive, or at least entertaining, and I hope, if any of the above resonates, some of y’all will join me. I’ll bump this post on April 1 once the source is live, and if others would like to also post your stuff, please piggyback on the thread – or just quietly update IFDB or upload to the IF Archive so as not to draw attention to yourself, that works too.

I hope to see you then, if only to distract from the atrocity that is the Eleusinian Miseries source code (Sting is only marginally better)!

45 Likes
2

I’ll participate, but I’ll have to wait until later to open source my upcoming game, because of Spring Thing.

One nice thing about Inform 7 is that all extensions are necessarily public source by their very nature.

6 Likes
3

Oh, I have every intent to publicize my SpringThing code after the comp is over. Then everyone can see the hilarious refactoring I do under time pressure, and the concerning lack of comments.

(Lack of comments is because I plan to do a major cleanup/reorganizing sweep on the codebase, which will include extensive commenting. Again, though, after the comp)

6 Likes
4

Oh same with me and my SpringThing! I am down :stuck_out_tongue:

6 Likes
5

Count me in. I release the source for my recent last place game. Time to tear it apart and learn.

7 Likes
6

image
You guys are commenting your code?!

All jokes aside, this is a really fun idea. My early IF dev dinners came with healthy servings of spaghetti, if you get my drift, so if abyone gets hungry…stop by my IFDB profile. BYOB (bring your own best-practices…)

7 Likes
7

image
image640×630 70.7 KB

Me on your IFDB page. :3 :sparkling_heart:

6 Likes
8

I haven’t read a letter of source code in my life, except snippets in the technical questions on this forum, but I have to agree with this from general principles.

Bad examples are at least as good a source of learning as good or near-perfect ones. They can be easier to grasp as they are closer to the student’s own level of skill, whereas perfect skill can feel esoteric and transcendent. Impossible to reach, so why try?

This might also be a good idea to showcase the many roads to Rome the various languages offer. Knitting and hooking together a bunch of statements may well result in a game that does something extraordinary in the player’s experience, just as well as streamlined, polished code. The knitted&hooked code may even give people more ideas for adapting it to their own needs.

7 Likes
9

I’ve already been publishing the source code for all of my dendry games, as well as my choicescript game: aucchen (Autumn) · GitHub (and I’ll likely be releasing the source code for all my future games as well). I don’t know if this is reassuring or not for people who are nervous because of their perceived code quality, but the number of people who will ever read your source code is somewhere between “no one” and “very few people” (plus the AI crawlers… which might be a better deterrent to releasing code than human readers, idk).

The source code for my games also function as essentially the only complete source of documentation for dendry, in case anyone wants to use that language…

10 Likes
10

I might consider this. I’ve spent three and a half years being too scared to show anyone my horrible baggy code so it’d be good to rip the plaster off.

7 Likes
11

Really can’t be by any worse than mine! All of which is publicly available…

8 Likes
12

It seems you haven’t seen messy source code… I’ve seen your source code for your latest game, remember? I think it was in a state where you were just working on it, not after some massive cleanup operation, and yet it was beautiful.

7 Likes
13

I love this idea and fully support it. This is particularly so because I teach classes (mostly with Inform 7) and there are many games that my students had wished had source code available to learn from. They didn’t want to pick apart source code; they wanted to learn how certain techniques were accomplished. (The historian in me also sits up at this and says that having access to source code is one way to chart the development of a code-based community.)

Regarding the fear of doing this, what’s always been odd is people often have less fear of releasing and showing potentially a “bad” game that has, say, horrible story, grammar or spelling issues, poorly written prose, or whatever else. Yet they fear releasing the source code to the same thing. It makes very little sense on the face of it. And I don’t mean this in a mean-spirited way. It’s just been one of those ironies that my students in my classes have always noted going on well over a decade now: they have no fear of releasing their source; they have fear of releasing what others might consider to be a “bad” game or story experience.

11 Likes
14

Ahhh, I’m so tempted to say that I’ll do a thread of “why your code is better than you think” reviews.

(I won’t, of course. That feels like it would be against the spirit of the thing and make it harder for people to decide to release their code)

But this is an old pet peeve of mine. Amateur or beginner code that’s written in pursuit of a particular result is NOT worse than professional code. In my experience it’s usually a pretty smart, pragmatic answer to a very different set of criteria. You’re not trying to make a thing that you’re going to keep growing and changing for a decade, to be worked on by a bunch of people who come and go over the years. You’re trying to tell one story. And once you have something, anything that works, looking for ways to do it better is a gamble that’s guaranteed to take time away from telling your story and might not pay off. You might find new techniques that take a big load off your shoulders and push it onto the computer, or that make it easier to do cool things without introducing bugs… or you might spend five hours hunting around with no result.

I bet you’re making smarter decisions than you think. Because honestly, even with years of training in helpful techniques and with much more knowledge about what’s out there? Many (I’d go so far as to say most) professional programmers are actually pretty bad at knowing (for a particular situation) when to call it good enough and when to say, “no, we need to find a better way.” I’d usually much rather work with an amateur who will trust their native common sense rather than get wrapped up in the educated -ologies and -isms of “good practice” that might not actually apply to their project.

/rant

21 Likes
15

Hmmm… if you were to password protect the source code file provided to IFDB and then mentioned the password in the listing description, would AI crawlers figure that out?

2 Likes
16

Agree 10000%.

3 Likes
17

Thanks :slightly_smiling_face: I always just feel like I’m doing things in an over-long way, break the DRY rule all the time, etc etc… but there have been a lot of good points made on this thread so I will get it posted up soon.

2 Likes
18

I feel like this, in particular, is a very crucial skill to have in software.

Ideally, you would want to find the best way before starting, but that’s like trying to identify all the blades of grass before landing somewhere. Sure, you could theoretically plan to that level of detail, but then you’re just coding that option, at that point.

There are things a developer won’t realize until they’re working on it for real, but being able to identify when to bail and choose a better option ASAP is crucial. Sure, you’ve wasted dev time, but you would have wasted a lot more if you would have stuck to it. In the end, it’s still a productivity boost (and practice).

Same thing with “good enough”, which is sort of a Goldilocks Zone. You will always be your own worst critic, but at some point you will just be spending unnecessary dev time cleaning up code that was already spotless. There is a point where code cleanliness loops back around to being unreadable again.

5 Likes
19

To add onto this, making if ain’t easy. If you’re able to put together a game that’s moderately stable and playable without traditional programming experience, that’s pretty damn impressive all by itself.

9 Likes
20

If I do this, I will definitely win last place, so nobody else has to worry about that. If there’s a good bit of code in my games, someone else wrote it. Everything is held together with spit and duct tape and propped on a wobbly stick.

Additionally, I am very, very bad at labelling versions appropriately, so I’m not sure what the final versions are.

8 Likes