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…
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.
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.
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.
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.
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?
Thanks 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.
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.
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.
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.
@JoshGrams I have totally operated under those exact principles. Hence my ~500 macros that abbreviate many common methods to two or three letters etc. (TADS3) I like the idea of modularity and expandability, and feel good about it when I do things that way, but I won’t hesitate to invoke your principles and crutch something together when I’ve just got so much else to attend to. @DeusIrae , unfortunately I won’t have any released code to share by then, but I like the idea! Although it’s probably quite few folks around here interested in reading TADS3 code, and even less who want to read 50k lines of it.
My game source is amusing to me, because I have been working on it since I very first learned programming of any kind. There are some blocks that have been left untouched since I was just a programming babe dabbling with finger paints. Anyway, I feel like we’re all in the same boat here, other than some individuals coming from a long professional coding background…
And the flip side: IF game code written by professional / highly experienced authors is worse than you think!
Most of my Inform games have source code posted. I don’t know how often anyone looks at it. But if you do, you’ll see an awful lot of “bang in a global variable, great, it works now”. A lot of “copy and paste a rule twenty times because that’s easier than coming up with an elegant solution”.
The core mechanic of a game might be carefully designed. (The goal/spell system of Hadean Lands is complicated and required careful thought.) But the more of a game you write, the less you worry about elegance. Towards the end you’re hammering in rules by brute force. Why not? Once you release it, you’re probably not going to update it more than a couple more times, so it doesn’t need to be clean code.
I’ll go farther. If people commit to releasing source code on April 1, I’ll meet you there and post the Hadean Lands source code, which has never been released in downloadable form. :)
(I was already planning to post it next year, on the tenth anniversary of HL’s release. But this seems like a better opportunity.)
I submitted 3 more source code files to the ifarchive (77 Verbs, Magpie Takes the Train, and Sherlock Indomitable), and will update my ifdb pages on April 1.
Uh, it’s like you’re saying I’ve been doing it wrong all these times. In fact, not only I design things thoroughly, but also do multiple passes on it, each time a refinement.
There’s pantser. There’s planner. And there’s me, “percolator”.
Honestly, as long as a playable game comes out the other side, there really isn’t a wrong way if it works for you. You could be commenting your code in Klingon for all it matters. I wouldn’t sweat it.
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.