Cool! It’s neat that it’s possible. I would use this.
I liked this approach, so I have extended the language to read the value of attributes from a file. Currently, it supports reading strings from .txt, .html, and .md files and Javascript arrow functions from .js files. The following is now legal:
layout: <<<intro_layout.html>>>
and:
on_start: <<<start_callback.js>>>
In a longer game, you’re going to split it up and use the %(file) include macro anyway, so this becomes a convenient shortcut for particular kinds of value that might be more uncomfortable to write inline.
I was re-reading your comment, and I think this is an intriguing & provocative statement. But is it true? When you say “most people” do this, it sounds plausible, but I wonder what you base it upon.
If it is true, it seems to point to something problematic. I love Minecraft, but I’m not sure that sitting down with Java & LWJGL is necessarily a great way to approach building a game. Silly example, but hopefully, it illustrates the point.
If we acknowledge that there is a lot of room for different approaches to the problem, perhaps a decision tree to lead potential authors to the best tool for them is warranted. For example, a prospective author with little affinity for programming will likely have a rough time with Rez, no matter how much they liked a game built upon it.
On that note, I recently implemented behaviour trees as an alternative to scripting behaviour. I wonder if a writer with a bit of logical thinking could build behaviour with a more technically experienced partner creating condition & query tasks that they need (these are implemented in Javascript).
Anyway, thanks again for your thoughts.
I think you’re comparing Minecraft to the wrong things. This isn’t Java vs. Unity/Unreal. You’re talking about putting a new language into the ecosystem: if you had a choice between Java/Zig/Io/Factor, why would you choose anything but Java? If someone else has gone before, you know it’s actually possible to make Minecraft in this language, and it’s not just a toy project where you’ll get halfway in and realize it just doesn’t work.
And I think that goes double for a community where a large majority are not programmers: you want to know that writers like you can learn this, and it’s a lot harder for you to learn/evaluate a new tool. Why wouldn’t you just stick to the tool you know and that lots of other people use? You know it can do all kinds of things and you know you can get help if you get stuck.
“Writer with a more technically experienced partner” does happen but it seems to be a pretty rare situation. If you assume anything other than “writer with little affinity for programming,” you’re aiming at a niche within an already small niche…
2 Likes
I had a feeling the Minecraft example would turn out to be a mistake, ah well.
What I was trying to get at is, if Dan is correct, that the tool one author uses to create something isn’t necessarily the tool another author should use, even if they like the product.
Your second point, about community and a prospective author asking themselves, “Can I get help with this?” feels on point. Of course, any new thing can struggle here, hence Dan’s point about pump priming.
I think you’re right that I am aiming at a niche within a small niche. It’s possible even that I am aimed at a niche of 1. I could live with that, although I would be disappointed. What tool creator doesn’t want to see his or her creation be helpful to others?
Thanks for the comment.
I misinterpreted your comment, Dan; you are likely correct: they start by asking themselves, “How did this get made?” and go from there.
1 Like
Ah, I see. That still feels like a programmer-ish rather than a writerly way to look at it. I don’t think “should use” comes into it. For non-technical people, learning a new tool is often a BIG investment and they’re used to computers requiring them to manually do things that could be automated, so that’s less of a big deal, and they’re asking “can my current tool be made to do this?” and not “is this the ‘right’ tool for the job?” and in fact a lot of people associate that whole mindset with jerks online berating them for using the “wrong” tool instead of just giving the quick easy answer to the problem in front of them.
Anyway. Rez looks promising, but uptake is slow. Do it for you. Even if you put a lot of time into making and sharing stories in it, writing documentation and tutorials, running game jams, etc., you should still expect it’s going to take at least 2-4 years to get much traction…
In my experience, this is very common in online discussions of music and video software. One of my favorite things about this forum is that in these circumstances – usually – a questioner is given a “gentle” suggestion that maybe this or that isn’t the best tool (or method) – almost immediately followed by an example of how to do it anyway.
3 Likes