I've been bemoaning the slightly run-down state of IF interpreter software. (The confusing font preference system in Gargoyle is just one example.) The fact is that the big surge of open-source IF activity was the late 90s and early 00s. Since then, coders have been drifting out of the community, and the ones still around have gotten lazy. (I include myself in that indictment, for damn sure.)
As a community, we do not have a tradition of mentoring and fostering new contributors to IF projects. All of our projects were made by people (most often solo developers) who got excited and wrote a whole application or library.
I like to think that we've got a good software stack, which smooths the path a little. You can write an Inform extension or a Glk library port or a Glulx engine core or a Parchment web service, and it will fit into the ecosystem. But it still starts with a person showing up with enough energy to start, build, and finish an idea. If someone shows up who is curious but not committed, we nod companionably and wait to see what happens. The results, over time, are predictable: activity slows down and stops.
With that introduction, you'd expect me to go on and talk about mentoring. But I don't know anything about mentoring. I'm one of the control freaks! I'd rather work on my own projects than collaborate.
Anybody want to think about community-building? (Hopeful look around...)
(Of course a lot of my projects are specifications and tools that interoperate with other people's code. So I kick myself in the ass and make it happen. But my natural talents do not lie in management.)
In this post, I'm going to talk about my plans as a solo IF tool developer. Warning: I will also talk about money.
I have a whole list of things I think Need Doing In IF (see footnote) but the one I intend to tackle next is Glk 2.0. This is pretty much the same Glk 2.0 plan I've been planning for years, but since it's been years, not everybody may remember it. (Or perhaps you remember it with bitterness and loathing, in which case I apologize.) In any case, I will explain it from the top.
The plan is: integrate Glk (the Glulx VM display layer) with CSS and Javascript. That is, you will be able to distribute Inform games with custom stylesheets and special display effects (see Vorple).
Why CSS and Javascript? Because they have already conquered the universe, so we might as well give in to our anger and rule at their side. Also, the most commonly-used IF interpreters are written in Javascript, which makes adding these new features trivial. (If we plan correctly.)
So how do we approach this? I'll admit up front that this plan isn't complete. This is a sketch; I have parts of it worked out.
The basic idea is to define a canonical HTML representation of Glk output. Or rather, a canonical DOM representation. (The DOM is the internal data structure that a browser builds when it reads in an HTML file.)
Currently, the Glk spec describes output in terms of windows, text, and text styles. The new spec will explain this in terms of HTML <div> and <span> elements, and the CSS classes for each one.
I don't mean that your Inform code will output HTML. For simplicity, and to maintain a clean separation of concerns, the Glk calls in the Inform library will remain the same. You'll set a style and print some text. The interpreter's job will be to either translate those calls into HTML (as defined by the spec), or do the equivalent job of text display.
Nor do I mean that interpreters will have to support every crazy CSS trick that Firefox is capable of! Far from it. The idea is this: whatever display capabilities the interpreter does have, let CSS guide where it's used.
It's easy to misunderstand this. Let me lay it out in an organized way.
- This is a change to the way the interpreter (Glk library) manages the display, not a change to the way you write your Inform game.
- But there will be some new capabilities available for Inform games. Mostly this will be about letting you use more styles.
- The display of a stock Inform game will not change much. Any changes will be in the direction of more uniformity between interpreters.
- This should not require interpreter maintainers to rewrite their code from scratch.
- Javascript interpreters (Quixe) will work by generating HTML information and shoving it into the browser display. This is how Quixe has always worked. I'll just have to add the CSS and make some adjustments.
- C interpreters (Gargoyle, WinGlulxe, Zoom, Floyd-bot, etc) can continue to work the way they work, by calling OS-native text-display calls (or use SDL or telnet or whatever). However, to decide on text display attributes for each style, they should start using CSS information. I will provide a library to make this easy.
- Alternatively, C interpreters could switch over to HTML display. That is, they could throw up an OS-native HTML widget and shove HTML into it, just as Quixe does. This is optional, but it has some advantages -- see below.
- The new plan will initially be available through an I7 extension. I expect that some future I7 release will make it the default.
- What new features does this plan give us?
- A game author will be able to include a CSS stylesheet with the game. This will customize the way the interpreter displays the game.
- A player will be able to select a CSS stylesheet as an interpreter preference. This will customize the way the interpreter displays the game (overriding the author's stylesheet if necessary).
- There will be some way to display more and fancier styles. I know we had an argument about this a few years back; let's not restart it in this post. I haven't nailed down the details anyhow.
- A game author will be able to include a Javascript library (or libraries) with the game.
- For HTML-based interpreters, the Javascript will be loaded into the browser page (or HTML widget). It can then perform arbitrary display tricks. Glulx Vorple can be built on top of this.
- For interpreters which do not have an HTML layer (i.e. old-style C interpreters), Javascript tricks will not be possible. The game will have to degrade gracefully or give up.
Where am I with this plan? Not very far. Even after all these years.
I have a roadmap. I've just finished step 1. It will be a few steps more before anybody else has to start writing code.
Write a simple, dependency-free C library to parse CSS. Done! I thought this would be a weekend hack; it actually took many days of work, because CSS is just as horrible as every other Web technology. (No, I didn't search for prior art before I started hacking. Who do you think I am?)
Nail down the HTML representation and the Glk API changes it will require. Think about how it affects all existing interpreters.
Update GlkTerm to the new model. GlkTerm is a terminal-window library (it's built on ncurses), so it can only support a few text attributes -- boldface, underline, ANSI color. This is enough for a proof of concept.
Update Quixe to the new model. (And jQuery, while I'm at it.) Quixe is an HTML-based interpreter so it will allow the full range of CSS and Javascript fireworks.
Write the I7 extension that enables this stuff.
Write a lot of demos. (Not just to show off! Demos will let other interpreter authors know they're hitting the mark, display-wise.)
Update RemGlk and CheapGlk.
Unleash my reign of terror upon the world.
Easy, right?
You can reasonably ask how long all of this will take. Especially since I laid out much the same plan at least five years ago, and then again three years ago, and I've just managed to finished step 1.
Well, Hadean Lands is done. That's a big carcass off my plate. Also, for this semester I'm spending one day a week at MIT(*) and that's a nice regular schedule for working on the project.
(* But not this week, because it snowed some. And the Red Line caught fire or something.)
It's still a lot to promise; enough that I feel queasy just posting this post. I hate making promises that I don't keep.
Thus to the subject of money.
Post-HL, I would like to work more on open-source IF tools. I would also like to work on indie games that will pay the rent. (HL does not pay the rent in the long term, despite the stellar reviews I got this month.) There's also contract work and so on. Life balance, it's hard.
One way to converge these interests: find a way to crowd-source IF tool work. But this is not an easy model. It's not a Kickstarter -- it's ongoing work, not one big deliverable. It's not exactly a Patreon, because I can't give backers early access or bonuses. (But some people try this anyway?)
I'm signed up for Gratipay, which started as a tip model for GitHub users (but now supports any developer). I haven't publicized it at all; despite this, somebody is giving me 33 cents a week. (Thanks!)
Are there any other patronage systems which you folks think I should investigate?
(Note: I am not asking for money at this time! I'm thinking about ways in which I might ask for money in the future.)
I realize this is an awkward subject. Many people support IF software. I don't want to be The One Who Gets Paid while everybody else labors away for free. On the other hand, there's a lot of work that isn't getting done; this has been true for years. I can start to unstick this, but not to the exclusion of paying work.
Furthermore, the Glk 2.0 plan isn't the only thing on my plate. I'd love to get back to Tworld (the Seltani engine). I could dig into CocoaGlk and figure out why Mac Zoom occasionally crashes (and why Mac Inform 7 occasionally trashes my skein, and maybe why it occasionally eats somebody's source code...) I could spend some time experimenting with the rule-based language idea, zog help me.
What I'd really like is a patronage-and-voting system, where people could put money into different projects, with the understanding that the ratios determine how much time I put into each one. Does anything like that exist? (No I'm not going to build one.)
...Wow, this post has wandered in circles, hasn't it. A mix of plans, promises, positions, and pleas!
I guess I'm trying to figure out where the next phase of my life falls, relative to the IF community. I have taken stock, and this is what I see. Comments welcome.
Oh, right, the footnote. This is the list of IF tasks on my to-do list.
(It's not very consistent. Some of these are things that only I can do. Some are based in other people's code, so I could offer a patch but someone else would have to do a release. Some are work bits that other people could contribute to my projects... though, as I said, I'm a control freak. "Look over pull requests" is itself an undone item on this list.)
Write an I6lib test suite.
Integrate the graphics/sound GlkOte work.
Graphics and sound for iOSGlk.
Merge data-import/export from iOSGlulxe to iOSFizmo.
Upgrade Quixe/GlkOte to jQuery.
Finish the CSS parser. (done!)
Glk 2.0 -- the CSSening.
Fix all the CocoaGlk bugs. Release a functional Mac Zoom.
Add a preferences UI to Gargoyle. Fix the scrolling delays that have been reported?
Add integrated scrollback to WinGlk.
Figure out how to package Z-code/Glulx games as Mac/Win executables. (partially done...)
Release the Glulx debugger work. Support in GlkTerm (and CocoaGlk?)
Choice-based extensions for I7
Finish screenshotter, get it integrated with IFDB
Tworld for Twine fans.
Look over all the issues on my projects in GitHub.
Look over all the pull requests on my projects in GitHub.
A fake timer-event signal for remglk (thus, in the JSON API).
Validate (or comment on) all I7 bug reports.
Rebrand all my IF libraries to the MIT license.
No comment, except that you're splendid, and if I was a Medici I would hire you as the official court IF programmer.
Thanks for your work over the years and I hope we'll all see a lot more awesome work (and not just from you!)
I think the Gargoyle project is really important, because it has every VM in mind, rather than just the Glk native one Glulx. Whatever happens going forward, I hope that we'll be able to get Gargoyle updated again to include a new HTMLified Glk layer, with all the old VM support it has now. Gargoyle is one of the most important IF projects there is (no offense to GlkTerm), and I would love if I could be someone who could help with it, but my C knowledge is so minimal there's really little point. But maybe in the future it would be possible for someone to write a compatibility layer between Gargoyle's C and a .net/mono/node.js/python Glk layer, and we could make it work that way.
One note on the above plans: once GlkOte is updated it would be relatively straight forward to put that into a HTML widget, so that there can be a consistent display style across both web and desktop terps. Not that competition isn't a good thing to (and I want to eventually write my own competitor to GlkOte) but a consistent appearance will definitely appeal to the potential IF designers out there.
Might be worth signing up to Flattr (and linking it to your github acccount), too. I doubt it'll result in much more than you already receive from Gratipay, but unless you object to their business model on principle there's not really a downside.
To add to the chorus of "you should try this other service": I tried Gratipay briefly and ended up switching to Tilt/Open. Couple of reasons: a) Tilt allows people to make one-off donations as well (not everyone is comfortable with a recurring charge) b) notifies you when someone has made a donation and includes their email address so you can write them a thank-you. Gratipay doesn't give you info about donors except the total number (which might be something you actually want), but more annoyingly doesn't notify you about new donors. When I asked, that last item is on the to-do list for them.
On an incredibly premature note, you might want to consider custom HTML elements rather than divs and spans, depending on what browsers you plan on targeting.
Grumble. Sort of.
Why is your glk-css-html architecture the right way to go? You know I disagree with it (separation of concerns and the MVC-like patterns have proven their value). Is anyone else in the IF world experienced enough with software development to understand the problem? (probably, but you garner so much respect that almost no one will speak up) Should we discuss the problem and define it clearly (as a community) and then get volunteers to work on the bits?
And to reply to Dannii's comment about Gargoyle in that it is absolutely not the most important project in the IF world. The most important project is any author being able to deliver high quality, user friendly experiences to as wide an audience as possible. Gargoyle is an archaic piece of software that doesn't fit into any existing software delivery paradigm.
We need to think about that. How do we deliver content? Web. Mobile. What are the underlying mechanisms that will last a long time? Cloud computing is big and growing. How can we model IF material to fit into the cloud as a service. How do we build user experiences that leverage that capability? This is one of the reasons Twine is so popular by non-programmers. It is essentially software as a service IF, albeit in the strict form of CYOA.
I'm also in the do-it-yourself camp mostly because I never seem to be able to find willing collaborators for my own vision of things. I'm certainly less capable at tool development, but this doesn't mean my ideas or anyone else's ideas are less important than yours.
I'm not saying don't follow your list. I'm just saying maybe you should open up discussions on where your enormously valuable efforts can be best used. Maybe offer the community a say. So maybe a UserVoice for IF tools that we call can vote on and those of us that have the capability, work on those things.
We really should attempt to move past our long-standing work-in-silos approach to IF development. Collaborate. Discuss. Communicate. Share. Build something like an IF Foundation where we all contribute in our own way.
Now that would be something worth funding.
I don't remember your concerns with Zarf's glk proposal, do you have a link to a past discussion? I didn't like his first try, but his second try looked good to me because it was flexible enough that it could be sidestepped entirely if you wanted to. I'm pretty sure it would be flexible enough to implement your Channel IO system too.
I don't see why you'd say Gargoyle doesn't fit into any existing software delivery paradigm! And don't forget that Twine became famous mostly as a Windows exe, not a web service.
I think you're focused mostly on the future David. A HTMLified Gargoyle is our way to bridge the past to the future. Through something like enscriptem it is our way of finally getting Tads 2 and 3, Hugo and Adrift to run on the net. It's the best way I can think of to run 99% of the games in the archive as well as 95% of the games of the future (excluding the web Tads 3 I guess. Twine wouldn't need to run in Gargoyle, but it would be so trivial to load it anyway.)
If an HTMLified Gargoyle had the CSS/Javascript support to run Twine games, it should also be able to run TADS 3 webui games. HTML TADS for Windows can run webui games on the desktop - it just starts the game as a server in the background, opens a window containing a browser widget, and directs the server output to the widget. I believe Mike Roberts intended for most TADS interpreters going forward to support webui games as well as traditional TADS UI games, but as with many other IF tech projects, nobody has yet had the time/energy to make that happen.
At this stage, though, I would be happy enough if Gargoyle supported TADS 3.1+ games at all, never mind adding webui support. I would be more than happy to send a couple of dollars a month to someone (zarf, or someone else) to keep Gargoyle actively maintained and updated. It hasn't seen an official release since 2011, although I occasionally pull the latest version of the source off Google Code and compile a newer version for myself.
Dave, you have a big vision, and if I were managing a well-funded IF Foundation then those would be the right questions to ask.
But (a) I'm not and (b) I would hate being a manager.
I have never wanted to stomp on FyreVM or drive other IF models out of the barn. This is my path. I've laid it out because I know I can make progress on it. Our biggest problem right now is *lack* of volunteers, so embarking on a design venture which depends on them seems seriously non-apropos.
Just trying to elucidate a little the difference between Andrew's and David's approaches to client-server (if we call terp "server" and meta-terp like Lectrote, Gargoyle or Parchment "client") communication.
Web1.0 (or rather 1.5) had this approach: presentation was generated on the server, compressed and fed to the client. Client uncompressed it, parsed the HTML, populated DOM and presented to user. So all 3 of the MVC were effectively handled serverside.
It seems to me that steps that Andrew listed lead in this direction.
There's now another fad, or fully fledged fashion even: to serialize model on the server and pass the parts that presentation level needs in the form of, e.g. JSON. The client can turn JSON into tree quickly, traverse and call DOM manipulation methods directly, without HTML in between. Or even ditch DOM and use Canvas, that is up to the client. Sometimes it's called (together with focus on the user-generated content) Web2.0
I guess this is what David means by "separation of concerns and the MVC-like patterns".
Also, in the present model of Glk "data" are always pushed down from the "server", either as response to a command or as result of some timer, internal event.
If there are events on the "client", they need to be wrapped into user command as if they were a typed in user input that needs parsing. Please correct me if I'm mistaken about this point. For example, if UI decides to refresh the inventory window, it needs to issue "inv" command that would go into transcript etc.
If we take graceful degradation into view, maybe yes, all "client" events should be equivalent to user parse-able input.
But if we stretch web app metaphor this far, maybe there could be just JSON requests posted from client (does Glk include this?)
I don't know enough about the issues involved to comment on the CSS plans.
I do think Gargoyle is super important for parser IF. And especially for people using Macs at the moment. It's the most up to date Mac interpreter, the only one with sound (and the sound is no longer up to date, and there are sound bugs) and it's still out of date with glk per se, and there are the darn preferences that should be in a menu. The fact that people have hacked Gargoyle just to get a popular game to run (eg Counterfeit Monkey) shows how important it is that it needs to be fixed.
A developer's attitude may be: it's not Gargoyle that necessarily needs fixing, we just need a good new Mac interpreter. But I assume if all that work's already been done on it, why duplicate it? I also assume a result could be gained faster by building on what's already been done. And Dannii has pointed out why Gargoyle has qualities that are useful for IF in general.
I am a game maker and not really a tool maker. In that capacity, the Gargoyle thing has been hampering me for years now. I can't fully test my IF games on my own machine and it's a pain to release them with even more potential-player-repulsing caveats than usual. I am about to release a game which has and will suffer from both the above-mentioned problems, but I'm reluctant to delay because I want to start on the next thing.
and they say commercial IF is dead... truthfully, I'd gladly tip IF authors I enjoy if they had some Tip button in their sites. I know one shouldn't rely on that, but having a tip button in this day and age of online monetary services such as paypal should go a long way towards a new era of patronage for arts.
anyway, this is about tool making, not games. I'd still be willing to contribute somehow, so you guys decide what's best and let us know it.
I just burned 4 hours reading the rule-based language stuff. Did you ever find the partial-order sort algorithm you were looking for in Junkyard Wars? Your declarative-language friends seemed to have trouble even understanding the question for awhile. I'm dying to know how the story ends.
Your slides description at http://eblong.com/zarf/essays/rule-based-if/index.html was crystal-clear to me, to the point that I feel I could implement an interpreter (not compiler) within a day.
Granted, this is your least practical project, but I have my own programming language I fiddle with, and I've always loved rule-based programming as it appears in Inform7, so I'm interested in your ideas. (Seems you have no "run this rule/book" imperative; it's purely declarative ordering. Just need to state at least one rule to run after the ProgramStart atom.)
It's been a couple years since I've had time to play much IF, which was always my primary motivation for working on the interpreter side of things. I suppose that puts me in either the "lazy developer" or "drifted away" camp, though my heart is still with the community and there's a lot I would like to do with Gargoyle if I could find the time.
If you settle on a patronage service I am happy to send money your way. I doubt you want to tackle another large IF project straight away, but one approach would be to tie the Glk changes to a new game that relied on them. From a fundraising perspective, that would bring together the people who care about the interpreter ecosystem and the people who love your games, and maximize the contributions from those in both camps (like me).
Thanks for the comments, everybody.
I have added a Flattr account (https://flattr.com/profile/erkyrath) and linked it to Github. (I'm not clear on how the "things" list works. It popped up showing IosFizmo, but no other GitHub projects -- is this because someone once tried to tip IosFizmo? If so, they must have later withdrawn it.)
Tilt/Open seems like it's new to this sort of donation model, and maybe not widely used yet? I will keep an eye on it.
I agree that Gargoyle is important. Or rather: I think that GarGlk is important. (My impression is that Gargoyle is GarGlk, plus all of the VM engines, plus a little bit of launcher code to glue them together. I haven't dug into the code to see for myself, though.) Updating GarGlk and Gargoyle clearly needs to happen.
I also think that CocoaGlk is important -- Mac I7 is based on it, for one thing. If CocoaGlk gets bug fixes, then Zoom will be a viable Mac interpreter again (and I7 will be more stable.) That's not duplicating work; it needs to happen too.
(In theory we could ditch CocoaGlk and build GarGlk into I7 on every platform. But I am suspicious of that sort of monoculture.)
In a way, I think garglk is the least important part of Gargoyle. I doubt it would take too much to swap it out for another glk implementation. That's the point of the glk api. The important part, what makes it more than a Glulx interpreter, are all the glkified VMs brought together into one makefile.
When I say "important", I'm really talking about amounts of work. It's true that you could swap CocoaGlk for GarGlk and have a Mac Gargoyle with a different UI. What's stopping that plan? CocoaGlk bugs, which need to be fixed. Fixing those is important.
Or we could write a new Mac Glk library from scratch (too much work). Or fork my iOS-Glk library and adapt it to the Mac environment (probably still more work than fixing CocoaGlk, but available as a desperation play).
The work invested in GarGlk is valuable, but at risk if nobody uses it because the config UI sucks. Thus, fixing it is important. The Glkified VM engines are working fine, so are not part of this equation. :)
For whatever it's worth, I would donate money on a recurring basis to see more about the rule-based programming thingy. (In fact, I would write IF is such a tool existed. As it stands, Inform scares the hell out of me.)
I started implementing an interpreter for the language described in the powerpoint slides, partly to see if I could in fact do it within a day. Although I don't have a full day to spend on it, what I have at least has legs and "undefined identifier" errors. When I can write Cloak Of Darkness in it, I can share it with everyone.
I lot of zarf's ideas about it recreate the easy parts of Prolog (relations) and none of the hard parts (declarative variables, backtracking).
Honestly, I think backtracking is the part of Prolog that shouldn't be copied anyway. Declarative languages should actually be declarative, and not tied to a particular method of implementation!
The hard part, I think, is the "base cases with exceptions" model: ordering those exceptions (even considering that they may be defined in completely remote sections of code) is a nontrivial problem.
I agree. Ordering is the problem I've been butting my head against, on and off, for years.
I'm not willing to accept money for the rule-based programming thing because I don't know how to make progress on it! I mean, if I got a MacArthur genius grant I'd be happy to take a year off and just screw around with it. But absent that, it's going to sit there until somebody has a brilliant idea (or plugs away at stupid ideas until one of them turns out to be brilliant).
And I am in fact aiming at the latter: make an interpreter quickly/easily to prototype some of these ideas, and let Cloak of Darkness or whatever expose the issues empirically. It's a lot easier for others who don't geek out about PLs to understand the issues with [non-]working examples. More people = more ideas = higher % of getting a great one.
Understood. I agree, that's a good step to take and I've never taken it.
(I wrote a thumbnail Python script, many years ago, but I got bogged down in language syntax and never tackled the interesting questions.)
OK, I've posted some source code. Let's continue this rule-based language discussion at http://www.intfiction.org/forum/viewtopic.php?f=38&t=17512
I would recommend building your own voting site; that's not a hard problem. Once you have one, you'll have something that you can offer Patreon subscribers: exclusive access to your voting site.
Long term, the "right way" to fund you is as an in-house dev at a parser-IF publishing house, structured something like the way we've structured Choice of Games. Solicit pitches, pay in advance, and (this is the hardest part for parser IF folks to swallow) minimize innovative game mechanics in favor of tried-and-true puzzle categories.
The goal would be to publish a large number of games on as many platforms as possible, with acceptable puzzles and top-shelf writing. Think of Telltale in its early days, churning out point-and-click adventure games with tried-and-true inventory puzzles and licensed IP: Sam & Max, CSI, Strong Bad, Wallace & Gromit, Monkey Island, etc.
I'm guessing you don't want to run that business yourself, but, speaking from experience, it's just straightforward hard work.
That's what Dave was trying to do with Textfyre, but it didn't get enough traction.
You're right, I don't want to run that business. I would love to be employed as tech monkey by that business. But, even if it's possible, your own experience shows that it could be years before the company has enough budget headroom to look beyond the day-to-day "acquire games, publish games, market games."
I like the idea of Patreon access to voting (dev forum, discussion, etc.)
I think the timing with Textfyre was wrong.
Look at Dan's blog posts back in 2010 when they lost Google ads funding. There was lots of "nobody will ever buy a CYOA game!" type comments.
https://www.choiceofgames.com/2010/08/were-banned-from-google-adsense/
What seemed to save the business (Dan, I'm just extrapolating from the fact I follow indie game biz obsessively, feel free to correct) was people started to buy apps, for real, while CoG stuck to its guns and kept putting out genre-related product.
Textfyre put its last product out in 2009 which was a smidge too early.
I am pretty sure now is the time someone could pull the parser business off. It will need some new and steady product, though.
Late to this, but I thoroughly enjoyed the Hadean Lands updates that you provided every month. If I'd known when this all started that I was going to get that out of it, I'd have gladly supported at a higher level than I did. All this, even though, given work demands on my cognitive space, I'm not sure if I'll ever actually get to play HL, despite how awesome it sounds. You might be able to raise more than you think by offering a regular update for supporters on Patreon; don't underestimate the value people with disposable incomes place on the idea of living vicariously through helping a very talented person get to do what they want in a way that contributes to a community.
Late to this, but I thoroughly enjoyed the Hadean Lands updates that you provided every month. If I'd known when this all started that I was going to get that out of it, I'd have gladly supported at a higher level than I did. All this, even though, given work demands on my cognitive space, I'm not sure if I'll ever actually get to play HL, despite how awesome it sounds. You might be able to raise more than you think by offering a regular update for supporters on Patreon; don't underestimate the value people with disposable incomes place on the idea of living vicariously through helping a very talented person get to do what they want in a way that contributes to a community.