DemoQuest - Now general 'Quest discussion - Possible new team recruiting

[Pumaman]

Well, I guess that's part of the question. Should it try and show off arcade sequences and looping rooms, or should we stick to something simpler that throws in a few cool tricks along the way?

Theoretically you would only need a few backgrounds and a few characters to create a demo game -- but what sort of demo game should it be? Should it attempt to have a story, like the beginning of the current one? Or should it just be a "free explore" type game where the player just wanders randomly around clicking on things and sees various things happen -- and can then check the script afterwards to find out how it was done?

[TheJBurger]

I don't know what the current Demo Game is, but I've played 2 versions of it:

1- (the original?) you play as the guy in blue shorts and must get into the building where there is a ramp going out into space.
2- same as above, except the building is really the AGS factory, showcasing all of AGS's features.

I really liked the second one, and when I played it, it was a WIP. I think that the demo game should be just like #2--a factory that showcases all of AGS's features, so then the player can exit and look in the editor of how to do each one.

[ildu]

Why would it need a story, though? A guided demo with perhaps some kind of explained premise would be simpler, innit?

[monkey0506]

The idea of a story is a simple ruse to disguise the demo as something more than just a guided walkthrough.

But I do agree with Chris. Rick's idea of mini-games is probably a good idea as a sort of "expansion pack" method for the 'Quest, but we should definitely hard-code certain examples into the main body of the 'Quest which would be the initial feat. The question is which examples should be hard-coded and which are better suited as expansions?

[Rui 'Trovatore' Pires]

My two cents.

The big issue with the demo game in its current state is that it's incomplete - "open a door and go through and there's no room change"-style incomplete. "Go through this door for this, this and that - but they're not implemented yet"-style incomplete. "//In this room, you'll be able to solve this puzzle by going XY and doing Z - but there's nothing at XY"-style incomplete (that last one was a comment on the script).

This is a problem because the demo game should showcase AGS *and* be a starting ground for newbies, which RickJ did wonders with, thanks to his painstaking documentation in each room.

I'd rather a Demo Quest that delivers what it promises, 's all.

I could easily devote some time to DemoQuest, but my scripting is rather messy, not at all what you'd want in this demo game.

I believe all the current expansions should be hard-coded - the verb coin, the AGI, the parser, the arcade game, the looping room, the SCUMM. All of them except SCI Point and Click - I released it only for people making SCI-Style games who wanted an SCI look. Apart from the inventory, it's just a standard SIERRA interface, and it really makes no sense for it to be there, as it doesn't showcase much of anything.

Furthermore, I think the first task should be to put in the game what the game says there should be. I'm mostly thinking of the very first hall where you're supposed to learn the basics. It's rather vital, wouldn't you say?

Also, I'd suggest a separate room for expansions, dedicated for expansions. Or heck, just a file menu. Something that doesn't force anyone to leave out some empty door somewhere, waiting for an expansion that may never come.

[Dualnames]

wow... you  all  neverminded my comment. Ah, what the fuck. 8)

[ildu]

The two Wintermute tech demos, 3d and cartoony, are a great help, eventhough they're only single room games. I guess the main positive is that they're complete and marketable as learning tools. If the AGS demo game is actually incomplete and inconsistent with direction, guiding, and such, why not restrict it to a smaller game that's actually intact?

Could someone possibly list all the features that the demo game is supposed to have (gameplay-, design-, plot- and art-wise)?

[scotch]

I don't think there should even be a Demo Quest. A full game is not a good tutorial, it's too big to take in properly, and even if it's modularised it's still not ideal. If the goal is to get new users up to speed then self contained tutorials (not demos) with supplied artwork are the best thing. If the goal is to provide a reference to people that can already script on implementing certain advanced effects, then self contained demos are the answer. None of the demos/tutorials need to take more than a few days to put together. There's no reason to organise a coordinated team effort past making a list of tutorials and demos that need to be made.

I'd have no problem with donating a BG or two to a tutorial, but consistent artwork for a long demo game has nothing to do with teaching people and I wouldn't want to commit to that.

Edit: I do see the advantage of a demo that showcases the graphical, sound and script abilities of AGS, not for learning, but to assuage all these fears people have about needing 1600x1200 and so on. I'm sure plenty of artists around here would contribute, as long as it's kept very small. Doesn't need to be more than a room.

[OneDollar]

Could someone possibly list all the features that the demo game is supposed to have (gameplay-, design-, plot- and art-wise)?

OK, lets have a go at that then. Monster post coming up. Here's my list of things a demo could have...

Graphics
1) Showcase the best AGS can offer. 800x600 32-bit pre-rendered 3D backgrounds and characters, and high quality 2D background and character examples too. Lots of animation. Effects using alpha channels.
Pros
-People will see from the off that AGS can offer more than just 320x240 256 colour games staring a paintover of Roger
-Might convince people that the best AGS can offer is good enough for them
-Demo immediately looks impressive
Cons
-The time it would take to put together
-Needs some of the best AGS artists to put their time into it
-When it comes to pushing graphics, AGS doesn't go as high spec as Wintermute. It might not be wise to start competing with one of their stronger points
-Demo doesn't give that nostalgia feel that makes you remember games from your childhood, and makes you want to make something like them

2) Show just what can be done using 256 colours and low resolution. Use pallet cycling and other effects. Produce Monkey Island 2 type graphics and characters
Pros
-Show that 320x200 and 256 colours can be used very well if done properly
-Could mention that AGS can offer higher as well in a kind of "This is good, but you can also do better" kind of way
-Demo immediately looks impressive and offers a nostalgia to those who've played the Sierra/LucasArts games
Cons
-Might give bad vibes about what AGS can cope with
-Same problem with the artists, but now a different group of artists is required.

3) Make an average looking game and go for demonstrating features. It doesn't matter if the backgrounds aren't the best ever seen, or if the art is a little different in places, this is about the engine. 320x240 at 16-bit.
Pros
-Don't need to spend a huge amount of time on the art
-Several people can work on art at the same time without worrying about style clashes
-Potentially easiest resolution to work at?
-More time can be spent working on the demo itself
Cons
-While it might look ok, its pretty much guaranteed not to look the best it could be
-Style clashes
-Might put people off, thinking that you can only create old-school games with poor graphics

Gameplay
1) A series of tech demos and nothing more. Maybe very limited user control, such as changing parameters, but nothing else. Essentially a slideshow of things AGS can do
Pros
-Uncluttered, quicker and easyish to produce
-Less testing required
-Can be added to easily
Cons
-More boring for the user than other methods
-Doesn't showcase any gameplay
-Boring to make!

2) A slightly more interactive version of the above. The player can walk into different rooms where they are shown some of the things AGS can do.
Pros
-Demonstrates a little gameplay
-Requires more interaction so gets the player more involved
Cons
-No real gameplay is exhibited

3) More interactivity, in a similar way to the hall of GUIs. The player is told about a feature, then is allowed to experiment with it themselves within certain confines, eg a room that has a parser interface which the player must use to solve a puzzle.
Pros
-Demonstrates how the features could be used in actual games
-Involves the player a lot more
Cons
-Might be harder to develop
-Needs more testing

4) A demo masked as a game where not only can the player wander around experimenting with the functions of AGS, but they actually have to solve simple puzzles to get to the more advanced features.
Pros
-Lots of user involvement
-Provides goals, so players will continue to play rather than just looking at the features they like the sound of
-Fun to make!
-Hopefully fun to play
Cons
-The only way for players to see certain bits is by solving puzzles or hacking the source code
-The puzzles would have to be delicately balanced

5) An actual game. Story, proper puzzles, the lot. The game keeps bringing in new features as the player advances, such as changing the interface, or a puzzle that uses timers etc.
Pros
-User involvement
Cons
-Getting stuck
-Inbuilt linearity
-Potentially harder to make in a group setting

Story
1) Have a plot, story, characters to talk to, points to score
Pros
-Player involvement
-Allows for creativity when making the game
-Opportunity to show our friendly and humorous sides to get more people onto the forums and into the community
-More fun to play
-More fun to make!
Cons
-Extra time needed for designing
-'Redundant' graphics required
-More work

2) No story, just demos
Pros
-Easier and quicker to make
Cons
-Makes us just another faceless engine

Actual content
1) Stuff happens without being flagged up in demo, and its up to the user to think "I wonder how they did that" and go and check the script themselves
Pros
-Allows programmers to concentrate on getting the code straight and well documented
-Demo runs more smoothly
Cons
-May not occur to the player to check the script
-Player may have trouble finding the demonstration in the script
-Player may not notice some poor programmer's masterpiece of 36 hours

2) Quick demonstration of something, eg "This is how a global integer works. You choose a number in this room and I'll tell you what it is in this room", where the user has to check the script to see what actually happens.
Pros
-Player gets an understanding of why you would want to use something
-Potential for more interactivity
-Opportunity to show off!
Cons
-Have to keep pointing stuff out

3) Demonstration followed by a brief explanation in game.
Pros
-Player finds out how things work as well as why and why they would want to use them
-Two explanations available - in game and in code
-Player doesn't necessarily have to find the demo in the code
Cons
-Two explanations

4) Actual teaching. Like the above, but the game goes through how the process works in more detail and is much more of a tutorial than a demonstration.
Pros
-Filter out some of the Beginner's Questions?
-Friendly explanations
-Immediately useful
-More interactive way of learning
-Alternative/supplement to the tutorials in the manual
Cons
-Slows the player down on the bits they already know
-Lots of text for them to read
-Is the point of the Demo Quest demoing or teaching?

5) Some kind of look and see teaching method. Game is designed to be run in a window with the code open as well, and the game points out lines of the code to the user
Pros
-Arguably the best way of teaching
-Encourages the player to follow the flow of the game in the script as it happens
-I've not seen it done before
Cons
-Would AGS let you do this?
-Can't make last minute changes to the script
-Quite hard to implement
-The easiest way would be launching the game using the debugging mode, but if the game's running in 320x200 or something it could be quite hard to see what's going on in game
-Potentially confusing for someone who runs the demo standalone

Continuity
1) Demo is released as sections are finished and added to the build. Doors refuse to open or don't take players anywhere. Stuff is mentioned in game that hasn't been added yet.
Pros
-Can add new sections in by, say, just changing a walkable area to teleport the player
-Don't have to worry about removing visible blocks or changing artwork
Cons
-Player is left wondering why they can't get to a certain place
-Player doesn't know what is missing or incomplete and whether they're running into a dead end or not

2) Demo is released as sections are finished, but missing sections are clearly blocked off in each release, and player is made aware that something is 'coming soon' or not finished yet.
Pros
-Player knows what they can and cannot do
-New additions may be more obvious in each new release
Cons
-Game retains an unfinished look
-Need to keep an overall idea of what will be added later and where

3) Demo is released in completely sealed off sections. There are no dead ends in a release. When a new release is being worked on, doors, objects, features etc are added to what is already there to link to new sections
Pros
-Demo doesn't feel unfinished
-Potentially easier to add to
Cons
-Each version has to be designed so that these places can be added to it

4) Multiple standalone demos. If a story is being used, these are parts of that story. For example, Demo 1 shows you how to use different GUIs in different places, and demo 2 shows how to do less inventory based puzzles, such as timed puzzles
Pros
-Depending on how it is handled, could result in quicker releases
-Allows each demo to remain compact and simple
Cons
-More artwork required?
-Lack of continuity
-Potentially loads of different demos
-Difficult to group/end up with a mess of different features in different places

5) The demo team generates a big list of things they want to show. Everybody picks a few features off the list and makes a demo showing them and how to do them. The demos are released as standalone and/or as mini games in a 'menu' program
Pros
-Quicker and more regular releases
-Allows people to concentrate on a few areas, and work on the areas they know most about
Cons
-No continuity
-Variation in programming styles/quality
-Every demo would be small and the end user would be left with lots of files to download to see everything


Personally
The first time I downloaded AGS was many years ago. I don't know what version it was, but DemoQuest II was the example game (I've never seen DQ1). I thought that was great, I'd just found the engine, hadn't played any games made with it and here was something that demonstrated how I could make all these different types of games right the way from the text parser to the LucasArts 9-verb system. It also presented a friendly face to the engine. Back then however I didn't think I could program and eventually gave up with AGS when I discovered you couldn't make a game using the interactions editor alone.

Couple of years later and after completing a computing A-Level (and discovering that programming was exactly what I had been doing with RM2K for several years) I came back to AGS and taught myself how to use it. DQIII is now around and I check it out, and frankly was a little disappointed. In the several years that I'd been away from the program, all DQ had managed to do was strap more of a story onto itself, replace it's main character with a girl and confusingly place all its GUI examples in mini-games that I couldn't initially figure out how to get to work. I'd never really looked at the code behind DQII so I didn't appreciate the massive amount of work that had gone into converting and documenting that. Aside from that DQIII disappeared for ages due to Rick changing servers or something, so I taught myself to use AGS without it.

I'm not really sure what the point of the above two paragraphs is, but I guess it shows you where I'm coming from. I thought DQII was great, and its exactly the sort of thing I'd like to work on. Adding a vague story, some easy puzzles, some stuff that has nothing to do with the features being demonstrated is not only a great way of housing the features it also makes the game and hence program seem more friendly. It also suggests ease of use - look its so simple to make a point and click in AGS that we stuck this character in here for you to have a conversation with, and in fact the whole demo you're playing is an adventure game itself. Plus it gives you more creativity and freedom to play around with, and that's why we're here right? Because we like making adventure games?

Those are my several cents, what I will (also) say is that you need to not only decide what the demo is for, but also who its aimed at. What kind of people are you trying to attract? Do you want new users to come in, get inspired and boost the catalogue of games? Do you want to show existing or newer users how its done? Do you want to combat the features of Wintermute and the other adventure game makers out there?

In my opinion, which you might have had enough of by now, graphics aren't all that important. What you want to demonstrate is the ease of use, the wide range of things it can accomplish, the friendliness of the forums. Also I would only use the mini-game module once, for demonstrating it alone, and with the files distributed along with the demo. The mini-game thing is too confusing for a newbie. I also see no reason why you can't have a couple of standalone demos as well, showing off AGS's hi-res stuff, or non adventure gaming abilities.

OneDollar
Typed but not read

Edit: And will someone give Dualnames some recognition?

[Galen]

Make the 256 mini-res version and also make an even smaller uber-res version?

[monkey0506]

Providing a very small DemoQuest that showcases some of the most basic features of the editor, introduces the user to scripting, and things of this nature should probably be the "root" of the game. It should allow the user the option of skipping over certain sections so as to sort of personalize the demo toward what they already may or may not know.

From here we could implement small tutorials of some of the most common interfaces. Again, it should serve the purpose of showcasing the interface while still teaching the user how the interface is implemented.

We could do this in just a few rooms with a small amount of graphics. But I hold to my opinion that many people are turned off to AGS by thinking that it isn't capable of anything other than low-resolution graphics. So we should probably go for at least 320x240x16 if not 640x480x16. The former would help to break away from the "pixelated" look given by 320x200x8 by allowing more color variations, but the latter would actually allow us to show users that AGS is capable of "higher quality" graphics (noting that the quality of the graphics actually has nothing to do with the resolution ). Of course 640x480 graphics would be more taxing upon our artistry department, so that should be taken into account as well.

Also I still believe the idea of a sort of "expansions room" would be a good idea. This could be where the more advanced features could be showcased. The room itself within the main demo could be a very simple room that could adapt itself automatically to available expansions (Listbox.FillDirList anyone? :). The expansions could be released as stand-alone examples, but then if placed in the same folder as the DemoQuest, the main game's expansion room could list and launch it from within the main demo.

The expansion room could also accept (optionally) a file (possibly encrypted to prevent anyone messing with it) that could contain a brief description of the expansion that could explain within the main demo what it is used for.

The mini-game expansion method has the benefit of making the demo more dynamic by making it possible to expand upon without having to actually release a new version. One potential draw-back would be that the source for the expansions would be stored separately from the source of the main demo, but if the user wanted to modify the expansion to see how things work they would have the option of running it as a stand-alone game or copying the EXE back to the main demo folder to run it as an expansion. I don't think that should place too much strain on the users' minds...

I think the main demo should be completely self-contained; no dead-ends with the exception of the expansion room which would, in the event no expansions are found, say something to the effect of "This room is here to accommodate for future expansions of the demo. There isn't currently anything here, but you can check on the forums to see if any expansions are available."

Regarding $1's post though:

Graphics Combinations of #1 and #3. I agree that we "don't need to spend a huge amount of time on art," but then I really don't want users to end up thinking only old-school "low quality" games can be made. Perhaps 640x480x16?
Game-play Combination of #3 and #4. Any puzzles would have to be very simple. We don't want to deter users from playing and learning because they get stuck on a puzzle.
Storyline Combination of #1 and #2. A storyline could help keep the player/user interested, but we don't want to make it so engaging as to actually detract from teaching them about AGS.
Actual content #3. The game should be inclusive enough to actually teach the users while they play. And in a project such as this, code should be well commented to assist new users.
Continuity Combination of #3, #4, and #5. I don't see why everyone is so turned off to the mini-game idea. The game could be run as a stand-alone or directly from within the main demo simply by including the expansion's EXE in the main demo's Compiled folder. The only major draw-back is the split source, but I don't think it's that huge an issue...is it?

And what do you mean by typed but not read? You mean you typed it but didn't review it to make sure it made sense? Because I certainly read it. You came up with some great suggestions.

Oh, and Dualnames, I didn't ignore your previous post, I simply had no response to offer. If Rick hasn't been responding to your PMs I apologize, but I'm not really sure what I can do about that.

[OneDollar]

And what do you mean by typed but not read? You mean you typed it but didn't review it to make sure it made sense?

Pretty much. Took around 2 hours to crank that out, so I really couldn't be bothered to read it through again

I pretty much agree with your choices (as you may be able to tell with the way I worded the options and the pros and cons ). I'm not flat against the idea of using mini-games, I just didn't like the way DQIII used them - you download the demo and load it up, but then suddenly find you need to go back and get a load of other files in order to see any examples, a fact that wasn't even properly explained in the game. Using it in the way you mentioned would be fine, as long as there is a decent amount of content in the original demo to warrant having it there. We also need to make sure that any instructions regarding the use of the expansions are very clear - remember we're talking about the people who try and run AGS by just extracting the .exe from the .zip archive here.

[monkey0506]

I was thinking that idealistically (once we have the base demo and some extensions written) we could offer a "just the basics" download that would include just the base game, no extensions, and also a "full" download that would include several extensions (including copies of their source) into the archive. This full download would have to explain that the expansions are actually created as separate games, but they could be run from within the main demo if their EXE was place in the main demo's Compiled folder (presumably it would already contain copies of the "implemented" extensions). We would need to properly document the process, but it's not a difficult one, so I don't imagine documenting it would be that much more difficult. Also I do agree that the DQIII download set could have been better handled.

And of course when I was talking about "implement[ing] small tutorials of some of the most common interfaces" I meant actually building them into the root project. Scotch actually provided a very decent argument against a large DemoQuest project, which is why I feel that the root of the 'Quest should be kept small. If the main demo becomes too large it loses the focus that it was originally trying to maintain.

The demo is essentially there to introduce new users to the engine and the way games are made with the editor. It wouldn't take much to do this alone, though I think it we should probably also take this opportunity to introduce some of the most common interface examples (I'm thinking perhaps as few as parser, Sierra, LA Verb-box, and Verbcoin). The demo then would serve the purpose of showcasing the engine, while providing them with some sort of base to start their game from (their interface of choice). To me this seems ideal.

Of course feedback from more users would certainly be beneficial as well.

[LimpingFish]

I guess we should decide if we want a demo game or a tutorial game. If it's to be a tutorial, then surely what we need is, at specific points in the game, the onscreen character to address the player with explanatory messages:

"To learn how to make a character walk across the screen, go to..." and then list the location in the script with the relevant code, and the section of the manual that explains how it works. And similar messages for adding items to the inventory, specific inventory uses, etc. If someone was to put the time and effort into integrating a feature like this, they could make it as extensive as they wanted.

I don't really see the point of a "this is what AGS can do!" approach, without explaining how such and such is actually done. Unless we do just want a demonstration of AGS's abilities.

Of course, a regular game could do that just as well.

[OneDollar]

Of course, a regular game could do that just as well.

Problem is, if you go to a random entry in the AGS database, it might not be ATOTK. The other problem is the user might want to just jump straight into game making, completely ignoring all the games that have already been made. If they have a demo game either included with AGS or linked to on the same page that AGS is downloaded from they're more likely to take a look. Code aside, a solidly built, decent looking demo sells the editor to someone who's just downloaded it, saying "If you put the time in, you can make something like this".

I don't think the game necessarily needs to do the whole stating script commands in-game, it seems a little like doing everything twice. As long as all the code is kept neat and well documented the user should be able to find the bits they're looking for with relatively little searching. I do think the game should make announcements about "This section of the game will demonstrate..." though.

[monkey0506]

As long as all the code is kept neat and well documented the user should be able to find the bits they're looking for with relatively little searching. I do think the game should make announcements about "This section of the game will demonstrate..." though.

That's kind of how I feel about it too. But I do like one feature of DQIII which is a GUI that links the user to reference material in the manual. I think something like this which could also link them to the relevant scripts/rooms/GUIs/etc. as to what is currently happening would be very beneficial and help remove the need for "searching" the scripts. Pretty much what LimpingFish said there.

We're really getting some good suggestions about what could be done to make a more productive, more efficient, and more complete DemoQuest here, but it seems that only myself, OneDollar, and (perhaps?) Dualnames have shown any interest in joining forces (either joining Rick or providing him some relief as he sees fit). I was really hoping for a bit more enthusiasm here, but if no one shows too much more interest (in joining a team), I may begin negotiations with these two and Rick as to co-ordinating this project before too much longer.

[Ghost]

I would gladly contribute, but I am a messy, yes, sire, that's the very word, *messy* team player. Still, I think some background graphics or such would be possible if you can live with my style or I can adapt to the style that's chosen for the game. Scripting, well, I think there are more skilled code monkeys around... But well, graphics I can do.

I still like the museum idea I mentioned some posts before. It seems the perfect environment to demonstrate certain effects and features; you could actually have plates describing what will happen / be demonstrated in a room. And you wouldn't need to much of a story while you could still shove in the odd little puzzle. I really think that'd be the way to go.

As for the technical specs, I daresay a 640x480 game in 16bit will be more attractive to newcomers without pushing back the dinosaurs- I mean, hey, I'm 32, I can hardly expect a teenager who just found out that the genre of Adventure Games didn't start with Tomb Raider (*no offense*  ) NOT to shout that strange blocky things suddenly move on his screen- one pixel being approx. 2x2 inches in size  :o . Middle grounds, that's the key- not too much shiny tech stuff because then people will suppose that (since this is a demo) such quality can be achieved very easily, and will be diappointed when they learn that you actually need to do your x/y calculation by hand when using 640x480.

[loominous]

How about a modular solution that could feature everything from modern hi res 3D graphics like Myst, to two colour Atari Asteroids.

It could be done in a variety of ways, but the first idea that pops up is:


The Grounded Kid



(Screenshot from Willy Beamish)


The player would be confined to one or two rooms, being grounded, which would constitute the main setting.

The room(s) would feature various distractions however, in form of:

Consoles/computers:

Interacting with these would let the player access sub games/apps, featuring everything from lo res shoot-em-ups to calculator programs, to whatever the contributors are able to come up with (or have already come up with, which could be implemented).

(these could be presented in the computer/console menus as being only "Trial" or "Demo" games, explaining their (probably short) length).

Various Activities

Everything from (sub games like) playing in the tub with a rubber duck to tossing water balloons from the window, in attempt to hit the neighborhood grouch. These would however call for graphical consistency, so they wouldn't probably be very fruitful.


-

I think the main benefit of this approach would be a highly flexible and modular design, where anyone could contribute "apps" of all looks and types that could be launched naturally from within the main setting without having to worry about graphical consistency etc, and which could, in theory, be added to indefinitely.

So the player would hopefully find the style they want to pursue within it, and be surprised by the additional capabilities of the engine that they might not have discovered or considered otherwise.

I guess the biggest drawback would be a potentially huge size, but that could be countered by the main coordinator in form of selectiveness and app size restrictions. I guess the modular design could even be used to provide the option of downloading different versions of the demo game of various sizes, featuring different amounts of sub apps.

-

I guess this idea of a modular design featuring sub apps may suggest that I have a giant monster demo game in mind, but it could very well simply be one or two sub apps, an arcade game and a calculator, for instance. Doesn't have to be fancier than that.

[Evil]

I like how in depth your idea is Loominous. It would be hard to keep one style, but maybe as a community collaboration, it might work. Packaging it with AGS would make the potentially large file size less of an issue. If they're going to download it, they're going to download it regardless, especially if it's free.

[rock_chick]

I'm a bit worried by this statement -- AGS 3.0 already includes the latest DemoQuest and it seems to run ok. Is there anything you're aware of that's not compatible with AGS 3?

I'm not meaning to just bump this thread but came across this thread and this post caught my attention. I downloaded a version that was supposed to have the demo game but it doesn't seem to. Unless you're talking about the verbcoin template but I don't think that's it. If possible could you add a link to it or direct me a way to download it?