Messages

RawDrawing a character following an invisible character is quite easy. Assuming a full screen DrawingSurface called "background":

Code: ags

Viewframe *playerframe = Game.GetViewFrame(player.View, player.Loop, player.Frame);
//if you need to scale or tint the character, we create a DynamicSprite of him, otherwise skip this and use playerframe.Graphic instead of herosprite.Graphic later on  
DynamicSprite *herosprite = DynamicSprite.CreateFromExistingSprite(playerframe.Graphic);
herosprite.Resize((herosprite.Width*player.Scaling)/100, (herosprite.Height*player.Scaling)/100));
Region *playerregion = Region.GetAtRoomXY(player.x, player.y);
if (playerregion.TintEnabled == true) {
   herosprite.Tint(playerregion.TintRed, playerregion.TintGreen, playerregion.TintBlue, playerregion.TintSaturation, 100);
   }
else if (playerregion.LightLevel < 0) herosprite.Tint(0, 0, 0, 0, 100+playerregion.LightLevel); //not sure about the saturation setting here
//now to RawDraw the character
background.DrawImage(player.x-(herosprite.Width/2), player.y - herosprite.Height, herosprite.Graphic); // you can also wait to resize the sprite until drawing it by using optional parameters

However, I'm wondering how you handle background collision detection and pathfinding on a RawDrawn background? Presumably the character can't walk everywhere, so how does the invisible character know where to walk and where not to go?

If you have time, watch the multiple-hour interview with Fishman on google video: http://video.google.com/videosearch?q=Scientology:+Steven+Fishman+Deposition

I watched this a few weeks back, and I must say it's the most fascinating documentary I ever saw- and it's just an un-edited interview. It's excellent as an exposure of Scientology and their methods, but even more so as a portrait of an obsessive-compulsive guy with a religious mania. Everything he says is pure gold, and just wait till he shows off his collection of video tapes of his favourite TV show.

Edit: If it seems a bit slow at first, stay with it, the third part is where the madness really kicks in.

It really depends on your background style. Does the character get close to the camera, or does he always stay at a distance? Some people absolutely hate character scaling and try to design all their backgrounds so that the character won't need to scale. I'm happy as long as the character never gets scaled up, so I draw my characters quite big (around 240 pixels tall for my 640x480 game, though the backgrounds are letterboxed to 640x346).

Try to make a mock-up of the kind of background you want in your game and then see how large the character will have to be not to have to be scaled at more than 100%. Once you've decided on the size of the character, always try placing him in the background while working on it to see that it will work in-game.

Did you even check the manual? The function you need is Character.ChangeRoom(int room_number, optional int x, optional int y)

You'll want to look into the ListBox.FillDirList(string filemask) function.
In your case you would set up a listbox and do something like lstFileToLoad.FillDirList("*.dat");

And pay special attention to Dave's postmortem on The Shivah, where he discusses the mistake of releasing the original version for free. But also keep in mind that both Dave and Vince proved themselves by releasing freeware games before going commercial.

I doubt that you'd be able to sell enough copies to actually make a profit. With the cost of writable cds, printing, and postage, not to mention the work you put into it, you're already stretching the limit of what people might want to pay for a game they already downloaded for free. Of course it all depends on the quality of the game as well as the extras. But I think a better strategy would be to make a succesful game, release it for free to show people what you're capable of, and then start working on a commercial game. If you want people to have your first game on their shelves, release cover artwork for people to print themselves - in my opinion, the couple of bucks you could make by doing it yourself isn't worth the trouble.

Congratulations on finishing your game. I never played the first Sydney game, so I didn't really know what to expect. But overall it was a pleasant surprise. A bit of criticism though, and a bug report:

* The puzzles mostly made sense, although most of then consisted of running back and forth talking to people.

* As others have said, the inventory icon is a bit fiddly. I'd also like another way of closing the inventory window (eg. clicking outside it, or pressing ESC), since the placement of the SAVE, LOAD, PLAY, EXIT icons makes it easy to click EXIT instead of PLAY.

* Since you're not using an icon bar, the only way to change cursors is to right click. One way to make it more user friendly would be to add shortcut keys, or better yet, make the mouse wheel fully functional, so you can scroll to the previous as well as the next cursor (with current implementation mouse wheel up/down both work as right-click).

Spoiler

*Reading the card from Peta before showing it to Terrence makes the cursor disappear.

* The rope hotspot in the restaurant is hard to locate. I actually had to look in the code of the game to figure out how to get the lifesaver.

[close]

Did you set game.screenshot_height and game.screenshot_width to 320x200? Default is 160x100.

You should have darker blue at the horizon and lighter shades as you go up.

Actually, if you look at photos of a real sky, you'll notice that it tends to be the other way around.

Yeah, that's what I meant. And I agree there's plenty of game music that is worth listening to away from the computer (back in the day I recorded the end theme of Golden Axe (C64) to tape so I could play it on my walkman). But while some game soundtracks, just like some film scores, stand strong on their own, I still think it should be judged on whether it fills the purpose it was created for.

I think he's a good reviewer in general, but it seems a bit strange to critique game music out of context, and I found his review on the original Shivah soundtrack a little mean. I downloaded the midis and I recognize all his points, but I don't recall that the music ever bothered me when playing the MAGS release of the game. In fact it suited the mood quite well.

Well, you could set up an array of the character ID's used by cChar1, cChar2 and so on, and then iterate through that.

Thus instead of doing:

Code: ags

int n;
while (n < 10) {
   character[n].DoStuff();
   n++;
   }

etc.

You would declare:

Code: ags

int mydudes[10];

globally, and then in game_start you could define:

Code: ags

mydudes[0] = cChar1.ID; //or just the plain number, you get the point
mydudes[1] = cChar2.ID;
mydudes[2] = cChar3.ID;
//...
mydudes[9] = cChar10.ID;

then in the function, do this:

Code: ags

int n;
while (n < 10) {
   character[mydudes[n]].DoStuff();
   n++;
   }

This is looking very promising. I always thought the interaction editor should have been like this, to get newcomers introduced to scripting right from the start without intimidating them. The older versions of AGS always had this huge, horrifying gap lurking within it, which less experienced users would be exposed to when the interaction editor was no longer enough to achieve what they wanted. This seems a very good compromise. Great work!

The easiest way by far would be to use two characters. One invisible (transparency = 100) which would technically be the player character (who moves where you click, respecting walkable areas etc.) and one animated dummy character who follows the invisible character wherever he goes. The pogo animation could either be set as the dummy character's idle animation (with a delay of 0) or simply started using the Character.Animate with the eRepeat parameter.

If we assume the dummy character is called PogoBoy, then in your repeatedly_execute, you could put:

Code: ags

if (IsGamePaused() == 0) {
   cPogoBoy.x = player.x;
   cPogoBoy.y = player.y;
   }

Since the dummy character wouldn't actually "walk" anywhere, only have his coordinates updated, there's no need to worry about walking loops and whatnot, in effect fulfilling your wish to "set things up so that the characters animation is entirely independent of their movements".

What originally turned me off Wintermute was the licensing for commercial projects. Not that I ever intended to sell my game, but at least it's a nice option to have, once you've learnt how to use an engine.

That being said, I do think that the lack of finished games is what drives people away from Wintermute and towards the AGS community. Apart from Five Magical Amulets (and possibly The White Chamber), I haven't seen anything remotely resembling a classical, full length, third person game made with the engine. The fact that one of the earliest games, Dead City, and even the recently released Ghost in the Sheet are in first person (with static, original Myst style screens) gives the impression that making third person games in Wintermute must be cumbersome work. Perhaps it is, perhaps not, but I haven't seen any evidence to the contrary. Hopefully Once Upon a Time in Japan and Until I'm Gone will be able to prove this prejudice wrong.
Also, it seems to be geared towards pre-rendered backgrounds - for instance the dynamic shadows needs a 3D model of the environment to work - whereas AGS games mainly use hand drawn or pixel art. It's certainly easier to make a professional looking 2.5D game in Wintermute, and I acknowledge that a lot of adventure gamers prefer that style. But I downloaded the demo for Art of Murder (English audio, Polish text). And while it certainly looked a lot like Still Life, I noticed frequent glitches in character movement and screen changes. Perhaps it's the support of hardware acceleration that makes the engine more sensitive to different machine configurations, but it doesn't seem to be quite geared for what it's trying to accomplish yet. In AGS, on the other hand, I've at most experienced framerate drops when testing games on various hardware, the core experience has always been the same.

It sounds a hell of a lot like Don McKellar's Last Night. Lovely movie, and David Cronenberg's acting in it.

Radiant is right that it could be the graphics. But since it's an RPG, I assume you're using structs and arrays in your code. Even though every int or String in an array only takes up a few bytes, declaring a large array (10000 or so indexes) can allocate quite a bit of memory (and thus file space) to it, even before those ints and Strings are assigned values. You could possibly look into the dynamic array functions of AGS 3.0 to try to optimize the code - and in general not declare structs or arrays larger than what you'll need.

Sorry I haven't posted this earlier, but I was away all of last week. I'm afraid that the new date is too late in the month for me, so I can't participate this time around. Hopefully next year if Mittens is still set in Europe then.

It will slow down the game slightly since there's more pixels to move around, but unless you're using lots of graphics heavy functions (such as DrawingSurface or generating full-screen DynamicSprites), it won't be noticeable on modern computers. Especially not after the recent Direct3D implementation.

Your best bet would be to make a mock-up of your game using the same size of sprites and number of on-screen characters/objects that you think will be used in the final game. Then ask some of your friends to test it on their computers, providing you with their system specs and the frame rate count they got. This should help you decide the minimum specs for your game, and you can use that as a target throughout development, testing on a similiar machine on regular basis. If you do choose to include advanced effects that aren't necessary to gameplay (shadows, animated background objects and whatnot), you can always put in a toggle for them in an options menu.