Absolutely true.
It’s actually really surprising that source is shared so infrequently. I wonder what the mindset behind that is. Are they afraid people will steal their ideas? Or cheat? But cheating is only cheating the player, so whatever.
If/when I ever release something to play in any format, I’ll definitely release the source too.
2 Likes
Shame. 
I don’t care if players cheat and you don’t need to see the code to see the ideas, but I don’t want people to see my pig-sty of cards of hacky spaghetti code. 
5 Likes
Some people probably are worried about cheating. I personally would be more worried that better programmers will look at my code and laugh at my workarounds for implementation that probably could be a lot neater and better.
Ryan Veeder has published some amazingly-annotated source code examples for learning. Inform 7 lends itself to this anyway since the code is so inherently readable by non-coders.
My original intention for suggesting a speed-jam thing with no limits as far as what engine it’s done in was to compare how solutions present themselves in different formats. Sort of how Cloak of Darkness is meant to be a baseline to test how an engine handles some simple but fundamental scenarios.
I personally would love to see code and playable games showcasing how the best authors working would implement a similar scenario in Inform 7 and Inform 6 and Twine (Harlowe/Sugarcube/Chapbook) and Ink and Dialog and TADS and ChoiceScript and Quest and Sadako and Squiffy and CYS and Undum and whatever superior-from-scratch thing Harry Hardjono decides to do.
4 Likes
Um, I don’t have a name for that … yet, but all signs point to expanded ScottKit. So, Quill/Paw like system? Great Scott Kit? It certainly won’t match Inform, that’s for sure.
If this is common then whatever comp designed for code sharing is bound to fail.
I’m in the camp where any example code is better than none. I get the apprehension of sharing code that you’re not proud of, but it’s really helpful for new people (whether they’re new to IF or just that engine). The documentation for most parser engines is incredibly intimidating.
Honestly, Twine is the same way. You’ll get like a five paragraph blog post of how to print “Hello world!” and then it’ll direct you to the sugarcube documentation which is just a giant list of all of its functions with only the lightest of usage example code. You can’t really see how the pieces all fit together. Not like you could if you were comparing source to a playable game.
Anyway, that’s what I think.
As for embarrassing code, I’m a big fan of TDD, which is basically the principle that you should write the simplest code possible to get a test case to work and then refactor that code before moving on to the next piece. But in a competition, I’d imagine the refactoring takes a back seat to speed. So I’m sure your embarrassing code is just a few steps away from being presentable.
3 Likes
In my recent months of learning I7, one of my go-to tools has been doing an fgrep -R to search the Friends of I7 Extensions for some phrase or other and it has been helpful very often. So I’m a big fan of code sharing.
Actually, I’m going to go put the bunch of games I have source for under a common parent directory with the Extensions to facilitate searching them all at once.
2 Likes
My code is fairly neat and readable, but I rarely use any comments, except to identify blocks of code. Would that be a problem? I have no objection to sharing code, but I wonder whether anyone would really be interested.
I think the only reasons I’ve never shared it before is because:
(a) My published games have been done for jams or competitions, hence they’ve been done in a hurry and are never quite finished, but good enough for publication.
(b) I’ve been too lazy, or busy working on other projects. (My time management leaves a bit to be desired.)
I do have accounts on GitLab and GitHub, so if anyone’s interested, let me know and I’ll do something about it. Incidentally, my published games are in Adventuron or Inform 6 (PunyInform or standard library).
4 Likes
I don’t think it’s a problem. Especially if you have the playable game available so you can perform deductive reasoning on what is doing what.
I’m intending to publish the source code for my current (Adventuron) game in the near future. It’s a hilarious mish-mash of repetitions, redundancies, kludges and spandrels that will make real programmers wince, but it does its job and if it works, well: it works.
I’m sure there is a lot of value in releasing code (even ‘bad’ code) as there will always be something to learn from it - even if that thing is how not to do it.
5 Likes
I’d really like a small multi-tool comp and some source-sharing afterward. I have been tinkering, on and off, with a set of Twine (Sugarcube) widgets that simulate some of Ink’s functionality within a single passage with some lightly customized syntax thrown in, but it hasn’t had a trial by fire yet.
Also, I’m much more disciplined on externally-imposed tasks than if I try to blue-sky something on my own.
3 Likes
If this is about being able to compare source code for various systems, which I think is a terrific idea, then I think a speed-jam is not the best approach. Well-crafted code is not generated from tight deadlines.
On the other hand, a jam hosted on itch.io that has a short scenario, and no meaningful deadline (say 20 years), would result in some really useful source codes to compare.
Maybe there would be a new jam every year with a different scenario to implement. This might help get around the fact that different scenarios a likely to favor different systems.
The scenario should be very well defined and not a vague writing prompt because this isn’t about showing off individual creativity; it’s about showing off the systems. It’s also about being able to compare how other jammers approached various problems compared to your solution and perhaps learning something as a result.
I actually think the scenario for the first jam should be Cloak of Darkness or maybe and excerpt from Colossal Cave Adventure. It would be a nice low effort way to get the first jam in the series started.
1 Like
I think the deadline forces smaller games, which makes for shorter source code, which makes them less intimating to go through. In theory. I do agree the source probably won’t be polished, but the time limit may also dissuade the authors from laying too many complex systems on top of each other. So there’s pros and cons to both.
but a small, well-defined scenario would necessarily dictate the size of the game. Therefore, a deadline is not really needed.
I’m imagining a couple of years from now when a new system is made, the developer could join the jams and add their version to the pot.
Yeah, but then we fall back into the trap of the jam suddenly being parser only. I’ve made a Sadako version of Cloak of Darkness. It’s not great. Such a specific use of parser doesn’t work great in hypertext engines like Sadako and Twine, and it definitely doesn’t work well for CYOA engines like ChoiceScript and Ink.
The most notable issue with CoD is the darkness part. Instead of listing general directions “enter the cloakroom”, etc, I had to list cardinal directions because otherwise you couldn’t accidentally trample the message. It felt and looked dumb but I don’t know how else you’d manage it.
1 Like
I like the idea of a game, or maybe games, that illustrates how to solve different standard IF situations in different languages. CoD could be one of the games, but it’s a bit on the simple side. I would like games that also showcase, for example, NPCs, doors, conversations and many more standard and common things you’re likely to encounter.
The catalogue of games probably would be different, because of different coding problems you’ll encounter, for CYOA than for parser engines.
1 Like
Since we were talking about it, I decided to pull out my old Cloak of Darkness demo. It was one of the first demos I made with Sadako (go figure, right?), so it took a little bit of updating. Only a couple syntax changes happened between then and now, but a lot of features were added that let me streamline the code a bit, which was nice.
You can check out the demo here: Cloak of Darkness
Important note: The inventory button is the briefcase icon at the top left.
If you’re curious about the code, the repository is here, but the important bits are the sadako script and the demo related javascript.
The JS file is a bit complex due to attempting to emulate a parser game. A normal Sadako game wouldn’t need any of the functions attached to the game object.
4 Likes
Adapting a work to a new medium is always going to take more creativity than just porting to a new engine, and that’s ok! It’s more important to capture the feel of a game than every detail and mechanic. Sure, it would be hard to really capture the "enjoyment"of Pick Up The Phone Both And Die in a CYOA format, but doesn’t that just make it all the impressive when someone manages to pull it off well?
Yeah, but it’s better if you do the adaption because “Hey, wouldn’t it be neat if…” instead of “Oh. Is this the only way I get to play too?”