Adventure Game Studio

The AGS 3.0 thread isn't really the place for this discussion, so I'll start a new thread. It's not technically a technical question, so I'll post it in the Adventure-talk forum. If this is the wrong one, moderators, feel free to slap me with a moist trout.

CJ had this to say:

Quote from: Pumaman on Tue 22/01/2008 19:36:59I suppose overall my main concern with the demo game is the fact that it's a 256-colour game in what is a hi-colour world these days. Hopefully that shouldn't confuse too many newbies though.

I was wondering how many people would object to upgrading the DemoQuest demo game to 16-bit. 8-bit can be confusing to users who may be using AGS for the first time and are maybe trying to use the DemoQuest as a base to build around so they can get a feel for the engine.

If they tried importing any new graphics they would have to make sure the graphics were at 8-bit. They would also then have to work with the existing palette, which could definitely cause confusion: "Why are my graphics messed up?"

16-bit would also allow the possibility of showing the graphical capabilities of the engine. It's been discussed several times that one of the apparent "flaws" with AGS is that it apparently doesn't support "superior graphics", and only does "old-school pixel games". Perhaps if we included a higher-res example in the demo we could show that AGS can be used for more advanced graphics as well.

This all begs the question: Is it time to upgrade the DemoQuest to 16-bit? For the majority of users there would be no speed issues by upgrading. And it could open many, many doors for the 'Quest...you know...the ones that don't lead anywhere...yet. ;)

So...discuss!

Agreed, but who would do it?

I don't remember DemoQuest making use of any of the 256 colour features like pallet cycling etc (though I could be wrong), and that to my mind would be one of the main reasons of using 256 colours. An upgrade to 16-bit would make it easier to jump into (AGS's default is now 16-bit after all) and potentially easier to develop so I'd be for it.

Is there any particular reason for not suggesting going straight to 32-bit (and demoing alpha channel effects) if you're thinking of using it to demonstrate AGS's superior graphics?

As a side note, what's happening with DemoQuest development? Its something I'd be interesting in contributing towards, though I don't know if my programming ability/creativity is up to it, or if I have enough time...

The original DemoQuest did a palette cycle effect in the intro screen if I'm not mistaken.

I have to say that I liked the "original" DQ better than the new one- teh version where you controlled that little guy in the short pants and where you had the museum with doors to different GUI rooms. It was a source of much information for me. The new one is, in my personal opinion, better organised but not as complete.

Okay, it's easy for me to say we need a complete overhaul. But I think I can safely recommend updating to 16bit at least. AGS has become a Porsche with all the extras in the five (?) years since I registered here. It makes no sense to create a demo on the lowest specifications.

I should also say that I have great respect for the maintainers of the DemoQuest game- without their effort I'd probably not have lasted very long here.

Yes of course I meant the port to 16-bit as a minimalistic jump; 32-bit would be more of an idealistic jump from the graphical standpoint.

I have personally been working with the existing DemoQuest files to try and provide a "more complete" version as currently much of the 'Quest is non-functional, or just plain missing.

RickJ is somewhat of the forum's devotee however and he has contributed a lot to what we now know as the DemoQuest.

From what I can tell Rick has had somewhat of a time trying to maintain the demo largely by himself, doing a lot (if perhaps not all) of the work in the port to 2.7, then 2.71, 2.72, and I believe he has been working to port the code to a more compatible 3.0 version.

Surely one of the things that has always made working on the DemoQuest difficult has been the matter of source control; but perhaps if we could accumulate a dedicated team (that's not to say a team devoted to putting 8 hours a day in; but perhaps at least a few hours each week) then using the new AGS 3.0 and its source control capabilities we could find ourselves much closer to realizing this goal.

However this is digressing somewhat from the purpose of this thread which was to discuss what, if any, change should be made to the colour-depth of the DemoQuest game.

P.S. Ghost, it will be 5 years for you (as a registered member) this April, congratulations. You can check this on your profile ;)

Quote
I should also say that I have great respect for the maintainers of the DemoQuest game- without their effort I'd probably not have lasted very long here.

Ghost, thanks for the kind words they are greatly appreciated ...

Quote
I don't remember DemoQuest making use of any of the 256 colour features like pallet cycling etc

The intro screen and the "advanced" room leading to the arcade both use pallette cycling.

Quote
As a side note, what's happening with DemoQuest development? Its something I'd be interesting in contributing towards, though I don't know if my programming ability/creativity is up to it, or if I have enough time...

The development has kind of stagnated because of lack of help and feedback.  lately it has consisted of mainly keeping it updated to the latest flavor of the AGS scripting language.   Maintaining it is a lonely thankless task.   What usually happens is that people enthusiastically offer to help, do a few things, and then quickly loose interest.    Anyone, regardless of skill level,  is welcome to contribute provided they make a commitment contribute a certain amount of effort.   I don't mind mentoring novice programmers or working with novice artists as long as they are willing to put in the time and effort.

Quote
If they tried importing any new graphics they would have to make sure the graphics were at 8-bit. They would also then have to work with the existing palette, which could definitely cause confusion: "Why are my graphics messed up?"

Or they could just change the game's color depth first and then import their background.

Quote
16-bit would also allow the possibility of showing the graphical capabilities of the engine. It's been discussed several times that one of the apparent "flaws" with AGS is that it apparently doesn't support "superior graphics", and only does "old-school pixel games". Perhaps if we included a higher-res example in the demo we could show that AGS can be used for more advanced graphics as well

I would think that to show off AGS's graphics capabilities it would be necessary to draw new backgrounds and characters.  Converting the existing graphics to 16bit color will have no visible effect; they will look excatly the same and so then what exactly is the point of doing it?  Curiously enough I proposed this change many moons ago when I first started working on this and was quickly shot down ;). 

I think CJ's comments are reflective of the fact that the current demo looks outdated.  To remedy this situation, would require all new graphics, sounds, music, etc done with high color, high resolution, high quality mp3 music, etc.    Form there other technical requirements can be discussed.  For example we could limit the main demo to say 5 or 6  rooms and then the rest could be done as  mini-games.  The main demo could be easily distributed with the editor and the min-games could be maintained by different individuals.    Anyway, just a penney's worth of my thoughts

[edit]

Quote
I have personally been working with the existing DemoQuest files to try and provide a "more complete" version as currently much of the 'Quest is non-functional, or just plain missing.

monkey,  we should communicate about what you're doing.  I believe I have all the backgrounds and graphics either extracted or in a photoshop or other source format.  I also have new hosting space to support a development effort.   Also anyone else that is interested in helping out please send me a PM.

Quote
From what I can tell Rick has had somewhat of a time trying to maintain the demo largely by himself, doing a lot (if perhaps not all) of the work in the port to 2.7, then 2.71, 2.72, and I believe he has been working to port the code to a more compatible 3.0 version.

Just for historical perspetive, the biggest and most difficult task was conversion from the original DemoQuest II code base to the current form of DemoQuest III.  The two arcade games and all the GUI examples shared the same global script file which made it a tangled mess to organize.   This is not to disparage those who contributed to DemoQuest II.  When that version was produced there was no such things as modules or mini-games and so the only choice was to include everything into one global script.   

The second most difficult aspect of porting involved the conversion from old style strings to new style strings.  this affected the GUI example mini-games.  Litteral code translation just wasn't adequate in many cases and several of the gui examples just plain broke.  I was left with broken code that I couldn't determine what it was meant to do in the first place so the only other option was to remove  the unknown functionality.  I believe that much of what was removed were features from out of date game templates  that are not usebale with recent versions of AGS. 

I don't anticipate much difficulty in getting the current DemoQuest version to work with AGS 3.0.   However, adding code to demonstrate all the new features is another matter because they are many and I am not.  ;)   Seriously though, this is where a little feedback and some help could go a long way.

Quote
Surely one of the things that has always made working on the DemoQuest difficult has been the matter of source control; but perhaps if we could accumulate a dedicated team (that's not to say a team devoted to putting 8 hours a day in; but perhaps at least a few hours each week) then using the new AGS 3.0 and its source control capabilities we could find ourselves much closer to realizing this goal.

The difficulty here is that fact that AGS likes to keep everything in "one big file" and that makes it difficult for multiple to work simultaneously on the game.  With 3.0 things have gotten much better, with only the sprite being the one remaining bottleneck.  Mini-games and modules help out this situation quite a bit as well.  A manual source control system is in place where files are given revision numbers and ZIP archives are made for every major and minor release.  It's not  difficult to keep track of at all.   I suppose if there were 100s of developers I would be singing a different tune. 
=======

Again, my opinion is that the current demoquest should be made compatible with AGS 3.0.  Further I think we should be thinking about it's replacement with a more modern looking version some time in the near future.  When the current demoquest is retired we should make one last effort to make it as complete as possible and make one final release for posterity. 

The development has kind of stagnated because of lack of help and feedback.  lately it has consisted of mainly keeping it updated to the latest flavor of the AGS scripting language.   Maintaining it is a lonely thankless task.   What usually happens is that people enthusiastically offer to help, do a few things, and then quickly loose interest.    Anyone, regardless of skill level,  is welcome to contribute provided they make a commitment contribute a certain amount of effort.   I don't mind mentoring novice programmers or working with novice artists as long as they are willing to put in the time and effort.



I recall PMing you and I recall never getting a reply..

This is late-night caffeine talk, but I just remembered how much I liked Inform in the early years and how impressed I was with its documentation...

What I wonder is if... something like "Museum of Inform" could be done as a revamp of DemoQuest. MoI is an IF game that showcases certain basic and advances features of the scripting language Inform, and it really is just a museum with rooms that house "code examples" as exhibits. Players can start the game and test out the features, and then can browse the game code and see how these features are scripted.

This is very boisterous and far-fetched, but a "Museum of AGS" could be made as a group effort. It could have rooms showing off different GUIs, certain puzzles, and players could be given a "guided tour"...

I like the sound of that. But of course it would be quite an effort. Just wanted to put down an idea- the original DQ basically was something similar to the "Museum", and I cannot help wondering if this was the best approach.

Quote from: RickJ on Wed 23/01/2008 00:14:46

QuoteIf they tried importing any new graphics they would have to make sure the graphics were at 8-bit. They would also then have to work with the existing palette, which could definitely cause confusion: "Why are my graphics messed up?"

Or they could just change the game's color depth first and then import their background.

The point was that many new users will probably be unfamiliar with the way 8-bit vs. 16-bit works so they probably won't understand the need to change the color depth first.

Quote from: RickJ on Wed 23/01/2008 00:14:46

Quote16-bit would also allow the possibility of showing the graphical capabilities of the engine. It's been discussed several times that one of the apparent "flaws" with AGS is that it apparently doesn't support "superior graphics", and only does "old-school pixel games". Perhaps if we included a higher-res example in the demo we could show that AGS can be used for more advanced graphics as well

I would think that to show off AGS's graphics capabilities it would be necessary to draw new backgrounds and characters.  Converting the existing graphics to 16bit color will have no visible effect; they will look excatly the same and so then what exactly is the point of doing it?  Curiously enough I proposed this change many moons ago when I first started working on this and was quickly shot down ;).

I understand that converting 8-bit to 16-bit won't automagically make the existing graphics look instantly better; the point was that if the game was upgraded to 16-bit we could then have the option of using higher quality graphics whereas if we stick to 8-bit then this isn't a possibility.

I'm not saying that all the graphics should be reworked; I actually think there should be a range of graphics to demonstrate the capabilities of AGS. After all, isn't this what the "demo" is for?

Quote from: RickJ on Wed 23/01/2008 00:14:46I think CJ's comments are reflective of the fact that the current demo looks outdated.  To remedy this situation, would require all new graphics, sounds, music, etc done with high color, high resolution, high quality mp3 music, etc.    Form there other technical requirements can be discussed.  For example we could limit the main demo to say 5 or 6  rooms and then the rest could be done as  mini-games.  The main demo could be easily distributed with the editor and the min-games could be maintained by different individuals.    Anyway, just a penney's worth of my thought

Again, we needn't replace all the graphics, but staying with 8-bit means we don't even have the possibility of using high color graphics. I think the DemoQuest primary distribution should be representative of some of the most common features, while still displaying the capabilities of the engine. Too much focus on features and we lose the graphics battle, but the inverse is also true. There is, IMO, a need for a compromise which isn't currently being met by the 8-bit version. I feel that 16-bit could provide a more equal balance.

@Ghost who beat me to the post:

The current version of the DemoQuest does feature somewhat of a museum within its bowels, unfortunately most of the example code has gone missing out of the distribution of the 'Quest. Again, I think that the DemoQuest should probably be distributed with the source for the most commonly used example rooms (perhaps with compiled versions in the DQ's Compiled folder and then compressed versions of the source in the primary DQ archive?).

Well, I tried helping with the visual improvement side of things in my own way with the Alien Roger template I made that prettied up the basic Sierra gui and Roger but CJ has not added it to the ags 3.0 templates (I'm not sure if/when he will).  I'm also pretty sure I offered to help update DemoQuest in one of the old discussion threads ages ago and no one took me up on the offer so I assumed the developers were happy with it the way it was.  I think graphically it could use a makeover, yeah, but I also don't think the graphics are awful or will turn people away from using ags.  The minigames and such show off some of the engine features quite well, in fact, and aside from some bug fixes it's probably fine as it is.

QuoteAgain, my opinion is that the current demoquest should be made compatible with AGS 3.0

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?

QuoteFurther I think we should be thinking about it's replacement with a more modern looking version some time in the near future.

This is a good idea, but I guess the question is whether we have the people and dedication to do so...

Also, while I liked the idea of splitting it into the mini-games, I wonder if in reality that has made it too confusing for people trying to run the demo? Maybe we should try and merge the mini-games back in, but keep them in separate script modules such that they are properly separated out?
This is why I haven't included the mini-games in the AGS 3 distribution, because the instructions on how to hook it all up would have been too convoluted and potentially put people off.

QuoteWell, I tried helping with the visual improvement side of things in my own way with the Alien Roger template I made that prettied up the basic Sierra gui and Roger but CJ has not added it to the ags 3.0 templates (I'm not sure if/when he will). 

Sorry, I must have missed that. For 3.01, we'll have a review of what templates are included and whether we should add extra ones.

If you need new high-res bgs and/or characters, why don't we have an extra Background Blitz and/or Sprite Jam, restricted to only high-res entries? Competition is always a good thing and it'd be nice to have the extra motivation of your art actually going to use at some point.

I don't know if I've ever played the demo games, but you don't really need a whole lot of art assets for one, do you?

The main problem I see with replacing the whole DemoQuest is that having some time, art skill and scripting abilities seems not to be enough. The poeple who make the "new DemoQuest" will create *the* showcase for AGS. That's great responsibility...

What ildu suggests makes a lot of sense- a group effort. Maybe a sort of rulebook could be compiled, setting in stone what needs to be included into the "New DemoQuest", and then... well, time'll tell the tale, no?

Quote from: ProgZmax on Wed 23/01/2008 05:21:44I also don't think the graphics are awful or will turn people away from using ags

You would be surprised by how much graphics can actually mean to some people. For some it's not a "nice addition," it's a requirement. It may seem silly, but some people actually would be very turned off by the low resolution and 8-bit graphics shown by the current demo; even to the point of choosing another engine.

I wouldn't object to starting a new version of DemoQuest 4 from scratch. We could even include all sorts of easter eggs about the barely-ever-released-and-even-then-in-a-crippled-state DemoQuest III. :=

No offense to RickJ, in fact major kudos to him for all he's done trying to keep the DemoQuest going. But if we do successfully spark a new 'Quest from scratch, I would really like to put as many in-jokes as possible. :P

The question then becomes: Who's serious? Who would be willing to start a new DemoTeam? As I said before, no one in their right mind could expect us to all make this a personal full-time job and spend 8-10 hours a day on it; however if we could get a sort of "dedicated team" who could devote at least a few hours each week, we could definitely get something going here.

I'm all-for this idea if anyone else wants to join me. I could take the part of lead scripter. I don't do graphics or music, my forte is with brutally forcing the computer to do as I wish. := If anyone is seriously interested and thinks they could devote at least part of their day-to-day to either a new or the current DemoQuest, I would be interested in hearing from you.

If the idea is to build something from scratch then I'm certainly interested. I'd count myself as a fairly competent AGS scripter, especially with the basics, and its the part I most enjoy, but I can also do sprites and backgrounds, though anything half decent takes me quite a while to do. I'm also willing to contribute towards writing story, dialogue and puzzles.

The two potential problems are...

1) I'm by no means the best in any area. There are several of the more advanced scripting techniques that I'm a little shaky on (I've not had the time to figure out the drawing options yet, for example), I'm not the best artist if you're looking to produce stunning artwork that will inspire people to download AGS and make their own games, and I've not got a huge amount of past experience (though I have made a game and been playing around with the engine for a year or two)

2) I'm unsure on the time I'll have. My uni semester starts next week so I don't have an idea of how busy I'll be at the moment. I can't (at the moment ;)) see a problem with the "few hours a week", but I will get projects to write up and exams to sit (and judging by today, at least one to resit :'(), so there will certainly be times I can't contribute at all.

By all means count me in for further discussion though, DemoQuest was really helpful and inspiring when I first downloaded AGS, and its a project I'd love to contribute towards.

And by the way, I'll add my thanks for the work that Rick and others have already done on the project ;)

Quote from: OneDollar on Wed 23/01/2008 23:46:01there will certainly be times I can't contribute at all.

Yes I do believe we will have to allow for any team members to still live their lives...we won't lock you in a cage and force you to perform for the viewers...much. ::)

But the point is that we don't need a team who will start, work for two weeks and then all quit. Which is why I keep coining the phrase "dedicated team". :-*

Not to imply that we "dedicate all possible spare time to the project," but rather that we're "devoted to finishing the project." ;)

The problem then becomes who do you (or we) as a community consider to be the best artists/musicians, and do you think they have the time and/or interest for it?  I'm guessing that the reason why DemoQuest exists at all is because rather than waiting and being consistently disappointed by a lack of 'great' artists having time/interest the people involved wanted to get something done.  Talented artists are typically quite unreliable in free projects, and there are a lot of reasons why that I won't go into.  If you can get excellent artists (and this would be purely based on opinion, since everyone has different tastes) then obviously there's potential.  I just think you need to be realistic about the whole 'making it look professional' goal.

This is a good point, but I don't think we necessarily need "the best artists/musicians"/etc. to pull it off. The DemoQuest doesn't have to be "t3h bestestest game evar made!!!11111pwntâ,,¢". I think so long as we can pull of "decent" graphics, music, etc. and provide a "decent" example of what AGS can do and how it's done then the project will be a success.

The idea isn't that we have to make it the same quality as a commercial game completely through start to finish. I just think that providing some higher quality examples would be beneficial to the demo as a whole whether that means starting the whole thing from scratch or just implementing them into the existing 'Quest. I'm open to the possibilities if anyone's interested in joining efforts ($1's interest being considered of course ;)).

Am I misinterpreting this? Is this Demo Quest game supposed to be a long game, or just a quick tech demo of the engine? I mean, isn't it enough to have perhaps two bgs (for showing walk-ins and -outs), one protagonist character, one NPC and perhaps GUI graphics included? If you don't have a need for a lot of art assets, you will be able to keep them pretty separate from the other elements (art not bound by gameplay). This way you can just commission two bgs from the same artist, and that would already be enough to deliver consistency on that front. If the artist then becomes unavailable, you can have another artist handle the two characters, GUI, etc. separately. I don't really see an issue with this.

Well in its current implementation, in addition to showing off the editor, the 'Quest is also designed to show how to implement certain GUI systems, things like arcade sequences, looping rooms, etc.

It isn't necessarily required to be a "long and engaging game", but it's intended to be more than "just a quick tech demo" as well. Which is where an "issue" could arise.

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?

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.

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

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

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?

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.

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

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)?

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.

Quote from: ildu on Fri 25/01/2008 12:35:21
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 ;D
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? :)

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

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. :P

Quote from: monkey_05_06 on Fri 25/01/2008 23:50:28
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.

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. ;)

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.

Quote from: LimpingFish on Sat 26/01/2008 22:40:55
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.

Quote from: OneDollar on Sat 26/01/2008 23:31:48As 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. :=

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*  ;D ) 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.

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

(http://marcus.krupa.se/AGS/wb.gif)

(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.

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.

Quote from: Pumaman on Wed 23/01/2008 17:08:04
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?

It used to be in this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=23083.0), in the first post.

But now it's only blank???

Quote from: rock_chick on Fri 21/03/2008 21:47:45
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.

The currently supported version of AGS (ie 3.0, available from the Download AGS page of http://www.adventuregamestudio.co.uk/ (http://www.adventuregamestudio.co.uk/) has the DemoQuest included, though you have to make sure you check the "Install the Demo Game" option in the installer. The more recent beta releases in this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33624.0) aren't official releases and as such don't have the DemoQuest included with them.

If you download version 3.0 and install the DemoQuest with it, you should be able to open it in the 3.1 beta versions. You can copy the DemoQuest files to your 3.1 beta directory then uninstall 3.0.

The original thread fell victum to the server maintenance some how.  It has been reconstituted here:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34048.0 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34048.0)

Well it seems the Demo game that came with the program doesn't even have a background for the room, however I look at the other thread and have downloaded the one that looks far more complete.
However upon trying to run it with the latest stable version it wont run because of lots of errors.
BTW, off topic I realise but with all these beta releases, any idea when the next stable version will be released?

I'm not sure where you're looking, but the version that is included with the AGS 3.0 download should work fine.

Make sure you download the installer version, and that you check the "Install the demo game" box when installing.

Then, open it using the "Open the Demo Game" option in the AGS folder on the start menu.

Quote from: Pumaman on Mon 24/03/2008 22:14:28
I'm not sure where you're looking, but the version that is included with the AGS 3.0 download should work fine.

Make sure you download the installer version, and that you check the "Install the demo game" box when installing.

Then, open it using the "Open the Demo Game" option in the AGS folder on the start menu.

I did all that and there was no such option, it's not big deal, I just thought it was strange. When the newest edition is released and I hear that may be soon, I will see if it works this time.