Fun Summer IF Speed Jam #1

I’m going through your game right now and I’m curious what engine you’ve written it in. It says Strand, but that seems like a CYOA style engine from my googling.

Whichever engine it is, it seems to not be very resource friendly. It took so long to load on my phone that my browser timed it out. And now that I’m playing it on my laptop, it’s using like 400 - 600mb of ram and anywhere between 20% to 80% of my processor (which is a 2.3ghz quad core). It even becomes nearly impossible to type at some points because it’s using so much processor power to… I dunno… mine crypto or something. :sweat_smile:

1 Like

Performance:

You’re right! What a hog. Over here I’m seeing 40% GPU and ~500MB, only 2% CPU here (as it’s all the GPU). Might vary elsewhere, depending on your webassembly support.

Perhaps this is the 60Hz refresh rate !!

On Windows desktop, you can press F1 and get the debug windows. Also the “tools” from the menu.

So i don’t need 60Hz for a text game i guess. I must fix this (thanks).

The interpreter itself uses only 1MB of RAM, as measured by the command line version running the same game (text only). What we’re seeing is the huge bloatware of WASM running on browsers. Or it could be the GUI (Dear Imgui).

Engine:

This is the Strand interpreter. You can build CYOA and parser games and hybrids of the two. There’s no real distinction.

Here’s the game source-code, to give you some idea of how it works.

spoiler alert!

https://stvle.s3.amazonaws.com/fresherz/map.str
https://stvle.s3.amazonaws.com/fresherz/fresh.str

Code could be tidied up and made clearer of course. Maybe take a look at a simpler CYOA game like Beakstalk

source:

https://stvle.s3.amazonaws.com/beanstalk/beanstalk.str

Oh, loading times might be slow from the itch server. After all it’s free!

this will be a bit faster.

2 Likes

I think the loading issue was the phone trying to load everything into ram. It’s just a crappy motorola e4 plus with 2gb of ram. It can run playstation emulators fine, but it struggles on more advanced stuff like nintendo 64 and even nintendo DS, just to put it in perspective. (Although maybe you don’t do emulation, so that’s not relatable benchmark, but it’s all I got.)

I actually did try running the amazon hosted one after I saw you reply to Jade about it, but it also didn’t load on my phone and I didn’t see a noticeable performance increase on my laptop.

As for GPU performance, yeah, that was hit pretty bad too. Like 40% or something, but I just have a RX Vega 10. But then again, it can run playstation 2 and wii emulation at 60fps without dropping frames, so…

Anyway, performance issues aside, it’s always cool to see new engines. Thanks for sharing the code. It makes it a lot clearer on how the engine works compared to the little bit offered on the official Strand site.

It’s kind of cool/strange that there has been a sudden surge of engines that adopt a “you type this specific command to do the action in this specific situation” method of parser input instead of Inform and TADS style method of defining a verb and letting the engine handle all of the different ways a user would attempt to piece the sentence together. It’s definitely a lot easier on the engine maintainer.

I have to write a lot of docs about how to world building and defining “reactors” - which are the templates to catch commands.

The base idea is:

FOO
* A
* B
* C

is a general template where; A,B & C can either be;

  • choices the computer makes = procedural generation
  • choices the player makes = CYOA
  • templates to match commands (reactors) = parser

This depends on whether FOO is either plain FOO, choice FOO? or object FOO@

re specific command matches, it’s not quite as simple, otherwise you get a lot of repetition and the inability to define general handlers.

Firstly, parser command matches are semantic and not syntactical. This is most important. This is done by having the parser parse both the reactors and the player input and compare the reduct.

Secondly there is the all important concept of scope. reactors are attached to objects so that their action is only in scope if the object is in scope. Otherwise you could type anything anywhere.

Thirdly objects can inherit, so default and general reactors can be defined on superclasses to save huge amount of work.

so

FOO@ GETTABLE
* name
a foo
* x it
It's one of those foo things.

Will inherit all the reactors of GETTABLE as you’d want.

BTW, these superclasses are also defined in the language and not in the core code. You make your own supertype lattices too, which is really handy.

For example subtype ROOM to make INSIDE and OUTSIDE, then give them default stuff like floor, sky etc. Then make all your locations use the appropriate supertype. Same for dark rooms etc.

INSIDE@ ROOM
* x walls
XWALLS
* x floor
XFLOOR

OUTSIDE@ ROOM
* x sky
It's up there.
* x ground
XFLOOR

Must write proper docs… :slight_smile:

1 Like

Oh wow. I didn’t realize that you made Strand. I’m sorry about the tone of my posts. I would have worded things differently if I knew I was talking to the engine author. :sweat_smile:

As for your syntax, I don’t know if it’s a testament to the clarity of it or my ability to pick up on syntactic nuance from having worked with so many differing languages, but I actually gleaned most of what you said just browsing the source that you provided. So, hooray!

As for writing docs, I haaaaate it. It’s by far the thing I dread the most about releasing new Sadako updates. My pipedream is that some day someone will decide to proofread my docs and edit them so they don’t sound like they’re written by a high schooler.

One thing I’ll say about writing docs though, I can’t even tell you how many syntax or logic errors I’ve caught in the code while writing the docs. I always write examples to go with the different parts of my docs and I always test them before copying them to the docs. They don’t always work like I expect them to, so writing the docs helps re-enforce the prooftesting. Also, when I’m writing the docs it forces me to explain in actual english (not just half-formed thought bubbles in my head) how something works, and sometimes it’s so obvious on the page that something is missing or incorrect that I need to go edit my code. So while documenting sucks, it’s had a dramatic effect on the engine itself.

My horrible documentation project for reference: https://github.com/Tayruh/sadako/blob/master/reference.md

Okay, so, I’ve had some sleep and feel somewhat less loopy.

5 entries out of 13 signups isn’t that bad, I think; for itch, I think the completion rate hovers around ~15-25%, so that’s pretty a decent haul.

I feel kind of sheepish, now, because I’d guess I put ~40-45 hours into my game over the two weeks, which is a lot of time! However, having two weeks, including weekends, meant it was more like a couple of hours a day mixed in with a couple of full day weekends. It seems like that was wildly out of line with the rest of the entries, and that’s part of why I was wondering earlier about restricting it to a weekend or a week.

I think that it would be really cool to have something like the recurring on a reasonably frequent basis, but I think it would be a good idea to directly state what the comp is intended to do.

If it’s to encourage people to make games and build confidence, it should be shorter - like, as an example, EctoComp has an under 4 hours category! - and explicitly framed with the idea of “something messy that doesn’t quite come together > not releasing anything” - and also maybe don’t rank all the games.

Anyways, I appreciate you setting this up. It was fun doing it.

3 Likes

No problems. I’m always striving to make improvements so criticism are most welcome.

Your docs are better than mine. I’m vaguely thinking of making docs as a sequence of “how to” tutorials so readers aren’t bored to death!

You’re right about picking up bugs and omissions too. Writing docs, you’re forced to explain something you thought was (1) simple (but isn’t) and (2) what the engine code actually does. Usually reading the code, you discover something missing or some edge case not correct.

Writing these jam games is also good. The more engine testing the better!

3 Likes

Yeah, but you’ve seen the entries. Not that they’re bad, but cutting them down to two day or seven days would give us what? Like a “hello world”? I’m kind, but really cutting them in half (and even your project) or to 1/7th would barely give anything worth playing.

Of course collaborations will be allowed in future Speed Jams.

I’ll add that to my growing list.

That was kind of what I was thinking: like a forum “monthly implementation challenge” where the goal is writing and sharing the code and getting feedback without the stress of material needing to come from an actual full game or WIP. Having people go “oh that’s cool, I didn’t know what “Strand” was!” “Ooh, that’s how you get make stuff look cool in Twine” “Oh, Inform can make sounds?”

Instead of giving a hard “you must do this creative thing only between the hours of 1600 and 1800 during a FULL MOON…”, maybe just have a “submit by the end of the month” - make it clear the point is workshopping and it’s more of an example/prototype than a full game.

Submissions needn’t make complete sense or be a full experience; anyone who is interested in making frogs talk (whatever the challenge is) can throw together a fragment in five minutes, or mull over it as a larger piece as a prototype scenario knowing there are people who will be interested in seeing how it works, being inspired, or offering suggestions.

Ideally doing this should not take from any author’s writing time, but should be a “prime the pump/palate cleanse” sort of activity. Nothing is better than taking a break from a long game and doing something else completely different for thirty minutes or a couple hours sometimes.

Maybe…if there was enough interest…we could make a “Workshop” category under Authoring and have a monthly implementation challenge posted and change it every month. People could post at any time, and also make suggestions what the challenge for next month should be?

(ohh, that would be so much woooork…surely the community won’t want something like that…dream on…Hanon… I could probably even make forum badges like achievements …oh…so much work…)

5 Likes

That workshop idea kind of goes along with the monthly idea going I was saying here, so I’m definitely on board with that. @fos1 seemed to really enjoy running it, so it’d be cool if he continued to be the maintainer.

The only other thing that I think I should add to the pot is that I think we should keep this an itch.io thing. I’m not a huge fan of the site, to be honest (mostly that it forces every game into landscape on mobile), but it beats the alternative which is clogging up ifdb with half finished tech demos.

2 Likes

Could submission be user preference? You can post something on itch (privately or not), you can upload one of the supported file types here, you can just paste your code into a message for other people to compile…etc. Just direct people where/how to get it working.

Perhaps specify not IFDB or IFArchive, these are game samples, not works that need an archive. Itch allows you to keep stuff private in Draft mode and they make zillions of dollars hosting, so I wouldn’t be concerned about that. I have experiments on itch in draft specifically for private distribution.

1 Like

Yeah, it was more about this than it being itch.io specific. The goal is just to prevent it from clogging up the archives.

Just curious, what are the supported file formats? I know pictures are fine, but what kind of adventure file format are supported? How about zip or txt or pdf?

Also, any maximum size?

Right now, the site settings are:

max attachment size 4096 kb

Screen Shot 2021-08-15 at 9.49.48 PM

2 Likes

I tried to upload an HTML file earlier and it was denied, which is kind of annoying. If the file type was allowed, would it prompt to download or would it try to launch? I know images embed directly, so I’m kind of curious.

I noticed HTML is not on the list. It could be added, but I think that’s one of the file types similar to .exe that people tend not to want to download directly and/or have open spontaneously in their browser for safety?

I’d say just zip your HTML along with any other supporting files for tidiness.

1 Like

Yeah. It’s true that most HTML aren’t standalone so you want to zip them anyway. The one I posted today was, but that’s because it was a small utility. However, Twine files are usually standalone, so that’s a pretty large amount of games. Also choice script games are standalone.

Not that I’m trying to present a case for changing anything. I’m just saying.

1 Like

I’m confused. Presumably anyone who’s uncomfortable with opening HTML files in their browser will refrain from browsing the web at all and isn’t on this forum.

1 Like

I’d like to note that these things aren’t quite the same - the goal of the first is to encourage new people and give them confidence; the goal of the second is for people to share knowledge. At least, that’s how I’m reading it. If that’s incorrect, please say.

I think it would not be very interesting to have a sort of “code snippets” roundup, but I might not be the target audience. I think if the goal is to provide a easy way for newer people to build confidence, something similar to this would be good:

except put much lower, like, 12 hours, so the expectation isn’t too intimidating.

Anyways, I’ve posted about this enough, whoever runs the future comps (if they do get run) can do as they judge best. I think it’s a good idea to have more low-commitment options and hope it continues.

2 Likes