Messages

Even in an otherwise perfectly designed game like Gabriel Knight those are present - the message that you had to write on the tomb with a brick puzzle, for instance.

I'm amazed how many people criticize this puzzle. Was there really any doubt what to write - aren't you basically replicating the original message you found? Or maybe I just solved it in the reverse order (planted the tracking device first), so the object of the message itself was obvious and I did it in my first attempt. The only actual "puzzle" element in it was figuring out the letters you didn't have translated yet.

Edit: Same thing with the tape recorder puzzle in GK2 by the way. I'm not sure why, but it seemed totally self-evident which words to combine. If you want to point out a bad puzzle in GK, how about the zombie vine swinging puzzle, or the rather vague Drachen-drei/clock connection.

Ideally, a well-designed adventure game doesn't need a walkthrough, at least not for it's target audience. And since nobody is making money off hint books and hint lines anymore, I see no reason not to redesign a puzzle if it stumps more than a few percent of your beta testers. As for a built-in hint system? That's a cop-out. Rather add some dialog or change a look-at description to nudge the player in the right direction.

However, I have absolutely to scruples looking up a solution rather than wasting half an hour guessing randomly what to do. When I was playing Runaway 2 recently, I ended up referring to a walkthrough for every third puzzle, and not once did I find myself reading a puzzle solution thinking "Damn, that was so obvious, why didn't I think of that?" but rather "Man, this game is horrible". Games are entertainment products, and if they frustrate you for a majority of the time rather than entertain you, the creators have failed.
That said, when I originally purchased one of my all-time favorite game, The Colonel's Bequest, I also bought the hint book. But since it took a long while before I got access to a PC to play the game on, I ended up reading a lot of the hints before even starting the game. And to be honest, I think that I enjoyed the game a lot more from knowing what was actually possibly in the game world. (I was quite young, and I think I would have missed a lot of things, maybe even big parts of the game such as the hidden passages).

To me, half the fun of Zak McKracken was to pick up everything I could get my hands on (giant bobby pin?) and criss-cross the world at more or less random. I've always enjoyed the paranoid logic of the game, where everything is somehow related  (in some ways it's like a comedic Thomas Pynchon story) and your job is to make these leaps of logic.

I eventually got around to play Maniac Mansion Deluxe, but while it was nice remake, it gave me a been-there-done-that feeling. It didn't give me anything, which the original version couldn't have done. And without the sense of nostalgia, I doubt I would have had much interest in the gameplay. There's a reason why games like this are rarely made anymore, and that those few that do come out are mostly a waste of time (Runaway 2?).
Sure, you could change some parts. Perhaps the money aspect could be removed, at least as far as travels are concerned, but that would also undermine the need for one my favorite parts of the game (Bermuda Triangle). If there was one thing I would change for sure, it would be to make the mazes more interesting. But a large part of your audience would already have played the original, and for these people, the puzzles are merely a matter of routine. I say make a sequel instead, that way you can fix what you consider problem and at the same time give everyone a new experience.

Titles longer than 99 characters??!?  :o Here I thought that "The Lord of the Rings: The Battle for Middle-Earth II â€" The Rise of the Witch King" was a horribly long name for a video game. I'd hate to see how the desktop shortcut for the game looks.

I don't have too much experience with recording equipment. But one way of avoiding getting a new sound card might be a USB microphone. I've been looking to buy this one myself: http://www.zzounds.com/item--SAMC01U

Yes, this should be perfectly possible. The simple way would be to just move one of the parts, and have a section in the repeatedly_execute code, where all the others are aligned to, say, the head for every loop. This is quite inefficient from a performance point of view though, if 40 on-screen characters had to be updated every frame.

Rather, you should write your own move command to ensure that all the parts move together. Depending on your scripting skills, you could use an array to keep track of which character parts belongs to which character (advanced). Or merely having a section in the function for each "main character". By doing it this way, you should also avoid any animation lag, which sometimes happens when using repeatedly_execute.

Something like:

Code: ags

function MoveChar(Character* soldier, int x, int y) {
   if (soldier == cSoldier1) { //let's say that cSoldier1 indicated the torso of soldier 1
      cSoldier1.Walk(x, y);
      cSoldierHead1.Walk(x,y);
      cSoldierLegs1.Walk(x,y);
      cSoldierArms1.Walk(x,y);
      }
   else if (soldier == cSoldier2) {
      cSoldier2.Walk(x, y);
      cSoldierHead2.Walk(x,y);
      cSoldierLegs2.Walk(x,y);
      cSoldierArms2.Walk(x,y);
      } 
   }

Etc.

An easy way would be if you could construct the sprite so that it, approximately, could be divided in rectangular areas (i.e. everything below 40 pixels was legs, everything above 70 pixels was the head,  between this, the left arm, torso and right arm made up 10, 20 and another 10 pixels of the width.
With that knowledge (and a few calculations to adjust for character scaling), it should be perfectly possibly to detect multiple areas of the same character.

Another way, which may be good if the above is impossible, or if the character animates a lot, could be to split him into multiple character overlaying eachother. Each of them would only have the parts drawn that they should detect (one for head, one for torso etc.). All sprites would be the same size so they would align properly. The easiest way to create the sprites would be to draw the entire character, then duplicate it and erase the areas which should be detected in that particular layer.
Depending on how many enemies you need on screen at a time, this could need quite a few characters and might be slow, seeing as they would need maybe four "part characters" each.

Actually region light levels DO go up to 200%. It's the character and ambient tints that don't accept luminances above 100%.

Another way of making your game smaller is to reduce the number of colors in the image before importing to a 32 bit game. I did a quick test where this halved the size of the room file (and the difference was even bigger after compressing the files). In most cases, 16 bit will still be smaller though.

If you mean King's Quest 1, 2 and 3, I would recommed using AGI, the engine which Sierra themselves used to make those games.

However, you would be hard pressed to find ANY adventure game engine which supports multiplayer (LAN/Internet) and chat.

Do all these buttons actually have functionality? If not, I think the interface should be redesigned and cut down a bit. There's nothing worse than an interface where some controls are just for show. Plus, it would make things more transparent for people who never used the Borland C++ Builder.

Try putting this in the global script:

Code: ags

function on_event (EventType event, int data) {
   if (event == eEventEnterRoomBeforeFadein) {
      cCracker.ChangeRoom(cEgo.Room, 160, 100);  
      }
   }

Maybe it's just me, but reading theatrx' original post makes me feel like I was on drugs.

Ashen answered most of your questions, but to clarify:

7) If you want to make the character walk into a room, just place them in an off-screen area (i.e. cMan.ChangeRoom(2, - 30, 100)) and then have them walk into view (i.e. cMan.Walk(50, 100, eBlock, eAnywhere)). Using eAnywhere is important as there aren't any walkable areas off-screen.

If you want to use the obsolete function, the code should be:

Code: ags

function interface_click(int interface, int button) {
   if ((interface == 2) && (button == 0)) {
      //The rest of your code here
      }
   }

However, if you want to do it in a more up to date way, go to the GUI Editor, select GUI 2, and double click the correct button (you must give it a name first). Then put your code within the script function that pops up.

People still use Netscape? Anyway, do you have a software firewall, and if so, does Netscape have the permissions it needs to access the network/internet?

Edit: LOL, just saw LimpingFish's response

256 color mode is a bitch to work with. Even the KQ remakes use 16-bit color even though the original Sierra VGA games only used 256. Seeing as you game has been out for two years, I think most of the core AGS game audience have already played it. And I think it would be a waste of time to change it too much. Even if the backgrounds could be rescaled, I think all regions and walkbehinds would have to be redrawn. If you want to release a new, slightly upgraded version (i.e. animations, additional puzzles) , I think it's fine. But don't obsess too much about size.

For your other game, Infinity String, I think 16-bit would also be fine for the alternate version. That way you could just export all sprites to folders (from AGS sprite editor), change game palette to 16-bit, and reimport the folders. Each background would have to be exported/imported manually, but the overall work wouldn't be more than a couple of hours. And since there would be no resizing, all regions/walkbehinds would remain.

RawDraw would draw the darkness behind characters and objects in the room. That was the original problem and the reason for using Overlays.

In regards to using a character - I didn't mean that it was difficult to align character and GUI, I meant it would be a bit of work for Lt. Smash if he was going to use that option. Because, as I also said, it is a bit hack'ish, and I agree with you that it's probably not a good idea to include in the module.
I don't think that the scaling/radius calculation would be very difficult, though the alignment may be off by a pixel or two. It's just a few lines of code:

Code: ags

cFlashlight.ManualScaling = true;
cFlashlight.Scaling = (radius/Game.SpriteHeight[flashsprite])*200;

Of course the vertical/horizontal scaling would have to be the same, but I don't know if the current module even allows them to be set individually. And it can't be bigger than double original size, but usually you don't want to scale sprites up too much anyway.

To follow up on the DynamicSprite issue:

It would actually seem that the alpha channel DOES disappear when the DynamicSprite is created. I could swear that this has been a problem in previous version, but I see nothing in the changelist to indicate that it's been fixed. Very strange. On the other hand I always have many problems with imported alpha'ed sprites, so perhaps this was due to some other conflict. This is an excellent discovery for my purposes, but now I must go add a comment to that tracker entry. Weird.

This is very interesting news to me, monkey. I've been having problems with an alpha-channelled DynamicSprite for some days now, and this could very well be the reason. Well, I've asked CJ to implement a function to remove alpha channels from DynamicSprites, so perhaps it will be possible in the future.

As a workaround for the antialiasing (but too hack'ish to implement in the module, I think), you could let the module handle the totally black areas (still with option of GUI transparency), and then add an alpha'ed sprite for the inner part of the cone as a character in the room. You would of course need to add a bit of code to make that character follow the GUI around.

Edit: Just saw your addition. I'll check it out myself now.

I haven't checked out the code, but if you still create the other black sprites by cropping the top left pixel from the cone sprite and then resizing it, it should retain any alpha channel (for that pixel) present in the original. Thus, if the edges of the original cone sprite is created to be 50% transparent, the other buttons should also be 50% transparent due to the alpha channel.