Random posts

Twine: eliminate the back button functionality in Sugarcane

Update: this is now built into Twine 1.4, so this script is no longer necessary. You can enable it in Twine 1.4 by writing "Undo: off" in StorySettings.

If you want to remove the browser's Back button functionality in Sugarcane, to prevent the player from rewinding or undoing moves, here is some script code that can do that.

Obsolete script removed: use Twine 1.4

Version history:

  1. 9/3/13 - Fixed several bugs. The Start passage no longer appears in browser history, Back and Return now behave differently regarding variables, and the Rewind menu items no longer appear in browser history.
  2. 26/2/13 - Initial.

Feel free to report any bugs to @webbedspace.

Donald Fuck

Game File: 

I return to the form of the scrappy, nebulously interactive essayistic art-game as the dog doth to his vomit.

Made For: 
Danni's picture

Pest Control in Space


My first (last?) Batari Basic game.

You are Harry the Space Bug Exterminator. You know how to exterminate just about any intergalactic pest. You even have your own custom space ship for clearing out some of the more... problematic infestations, and no hive is too big for you to handle. Maybe.

Seems like the New Horizons Space Life Megacorporation just hired you to take a look at their bug problem. They claim that space station residents are mysteriously disappearing, and they suspect it has something to do with that giant space wasp nest that's been forming around the exterior. You don't like the look of it, but somebody's gotta try and take care of it.


- You can destroy the hive and bees more quickly the closer you get to them, but if you don't leave yourself at least some distance you'll put yourself in great danger.
- Don't try to fly to the right of any bees unless there's an emergency. Once they notice that they've passed you they will try to ram into you.
- Clearing out individual rows of the hive will make the bee spawn location more predictable. Use this to your advantage.

You'll probably want Stella to play this on. Or I guess you could get it running on a real Atari 2600.

Made For: 
An event

MAX 100

Game File: 





Made For: 
Pirate Kart 2
deckman's picture

my first GT game (collab with mno)

Screen shot 2012-10-20 at 5.14.51 PM.png

i worked on a game with my friend mno called GUU STTOB! it's a text adventure that becomes slowly infected by a spambot. he did most of the work but i did some of the writing and a bit of the programming!

i still hate pygame but pygcurse does look fun...i might use it in a solo project some time

atuun's picture


Game File: 

I don't have a ton to say about this, it's just about some stuff that's been on my mind recently. Also, wanted to make a moderate-sized thing to try and figure out unity.

note: location in screenshot does not appear in game because unity is inherently not-figure-out-able. Also, it's a fairly big download.

Made For: 
An event
picobot's picture


Game File: 

embarressing yet amusing twine memoir detailing the day celebrating my birth for the 18th time in an over dramatic and silly fashion

sure why not

Event Created For: 
Made For: 
An event


Game File: 

Player 1 : Arrow keys
Player 2 : WASD

You win if you hit the other person before they hit you.

Made For: 
An event
snapman's picture

Weekly Updating 1: Grappling Hooked

In an effort to help this site grow, I will be giving weekly updates on my various experiments with Glorious Trainwreck's favorite democratized game creator, Klik & Play. I haven't used KnP in 8 years, during which I've learned a fair amount about both programming and game design by making games in other languages, and working towards obtaining a college degree in computer science (the last part being in the last 3 1/2 years). So far, returning to the event-based game design paradigm has felt extremely limiting. Many simple things I could do in more advanced languages are either difficult or impossible to accomplish in Klik & Play. What I've found very interesting, though, is that solving Klik & Play problems rely on both computational, and physical strategies. What would be impossible to do with the built-in object movements can usually be done with numbers, and what is difficult to do with the limited calculation abilities of Klik & Play can be assisted with the built-in movements, or other properties and behaviors of the program.

One of my later projects in KnP was an attempt at recreating the grappling hook, or "Ninja Rope" from the game Worms. At the core of my original design was a platform movement object constantly shooting particles at the grappling hook center point. I assumed that I could measure the distance from the player to the center point by the number of particles not destroyed by contact with the hook. Whenever the number was too high, I would lift the player higher. Eventually there would be some swinging code, changing angles, and everything would work out fine. Of course, this didn't work at all. The player quickly levitated off-screen, never to be seen again.

Yesterday, I took up the problem again. My first notion was to create chained object groups in even-odd pairs, aligning them by hotspot to action point. After a lot of testing various object selection methods (to some rather hilarious and frustrating results), I found a simple cycling scan worked best to build a segmented chain. I could easily manipulate the length by setting visibility cutoffs for chain elements with values higher or lower than the desired length. The biggest drawback to this multi-object line was the apparent refresh rate, due to the cycling update. With only 16 chain elements, the fastest I could rotate the construct was once per 30/100th of a second. I went as far as adding objects to calculate and visualize impulse speed (IE: letting go of the rope), but the results were inconsistent.

Today I plan to revise the system to a two-origin line, by calculating the end point of the chain directly, and drawing the line from both ends. This should effectively double the refresh rate, and thereby the maximum rotation speed. But by calculating the end point directly, the chain becomes not the driving force of the simulation, instead a visual cue. If the visual representation of the chain becomes broken slightly at high speeds, at least the actual positioning of the end point will remain consistent.

I have taken screen shots of this experiment, but I'm not currently at the computer they're on. I might post them later if people are interested in them. Next time I'll either talk about the difference between a swing simulation powered by update wait adjustments vs distance adjustments, or I'll talk about misuse of the built-in platform movement to approximate a limited physics simulation. Whichever people are more interested in. Or I'll post some pixel art. Who knows for sure!

Back in the heyday of Klik, I sometimes called myself "The Master of Useless Effects". I've spent a lot more time on game design balancing as of late, but sometimes it's just fun to make effects. At least now I have a better chance of transforming these ideas into finalized projects!

Twine macro: <<timedgoto>>, a simple timer

This is inspired by the Timer script used in Panic! by Astrid Bin and Stefano Russo. That script implements a sophisticated timer entity which can count down throughout the entire game, can draw itself in graph form in a canvas element, and can be paused and resumed. However, it requires multiple macros to set it up for each use, and it can be a bit cumbersome if you simply want the game to advance to a new passage after a delay.

I felt like writing a similar macro that would be shorter and more specific. This one, <<timedgoto>>, just automatically (and invisibly) goes to the given passage after the given amount of time has passed. Each use of the macro only functions within the passage that uses it - if you're using Sugarcane or single-passage Jonah and leave the passage by a normal link, it will be disengaged. Feel free to consider this a counterpart to <<timedreplace>>.

macros["goto"]=macros.timedgoto={timer:null,handler:function(a,b,c,d){function cssTimeUnit(s){if(typeof s=="string"){if(s.slice(-2).toLowerCase()=="ms"){return +(s.slice(0,-2))||0
}else{if(s.slice(-1).toLowerCase()=="s"){return +(s.slice(0,-1))*1000||0
}}}throwError(a,s+" isn't a CSS time unit");return 0}var t,d,m,s;

New: This now takes CSS time values, which are decimal numbers ending in "s" (for seconds) or "ms" (for milliseconds). You can use fractions of seconds as well as whole seconds.

Usage examples:
* <<timedgoto "underwater" 2.5s >> goes to the "underwater" passage if you stay at the current passage for 2 and 1/2 seconds.
* <<timedgoto $deathpassage 5s >> goes to the passage whose name is in the $deathpassage variable if you stay at the current passage for 5 seconds.
* <<timedgoto $playerType + "pit" 1s >> goes to the $playerType + "pit" passage if you stay at the current passage for 1 second.
* <<goto "Throne">> - This shorter version functions the same as <<timedgoto "Throne" 0s>>.
* This uses code parameters (that is, it accepts "strings", $variables, and "various"+$combinations of both, and its parameters are interpreted as Javascript), except that the final parameter (the time value) is separated from the rest and interpreted as a literal parameter.

Version history:

  1. 1-9-2013 - Fixed a bug where it caused problems with the (un-patched) browser Back button code.
  2. 18-4-2013 - Changed time units to CSS units, added "goto" variation.
  3. 5-3-2013 - Initial.

Feel free to report any bugs to @webbedspace.

Timer Test.tws9.42 KB
Syndicate content