Messages

IceMan, have you tried putting a display command inside the conditionals to see if the function is even run? Have you defined the LEFT and MODE_USEINV values yourself somewhere? Otherwise, you could try inserting eMouseLeft and eModeUseInv instead.

player.x returns the current x coordinate of the player character, wherever he is at that moment. You're not supposed to substitute it with anything else. The only thing you should change is npcname, which should be changed to the script-o-name of the NPC character. And of course you can experiment with the number (25) to make the distance greater or smaller.

The whole math part is just simple trigonometry (Pythagoras) to calculate the distance between the player and the NPC. Since the player character is static, that's not really necessary (you could just check if the NPC reached his destination x and y coordinates), but the code is a bit more flexible this way. You could for example have an NPC chasing the player like in 7 Days a Skeptic.

The easiest thing would be to put a statement in your repeatedly_execute to check how far the NPC is from the player, or (in case the player can't move during the scene) just check whether the NPC has reached his walkto destination.

Something like:

Code: ags

fuction repeatedly_execute {
   if ((npcname.x - player.x)*(npcname.x - player.x)+(npcname.y - player.y)*(npcname.y - player.y) < 25) { //25 is the squared value of the wanted distance, here I chose 5 pixels
      npcname.Say("You're dead meat, player");
      }
}

If the player is static, there's really no need for the whole trigonometry bit, but it should still work. You should also put in a conditional to avoid the check running before and after it's needed.

I agree with Evil that it's great for a semi-comic style. For a moment I was hoping for a 3D version of Conspiracy of Songo



Also, great texture work on the ivy.

From http://steampowered.com/v/index.php?area=game&AppId=400:

Minimum: 1.7 GHz Processor, 512MB RAM, DirectX 8 level Graphics Card, Windows Vista/XP/2000, Mouse, Keyboard, Internet Connection

Recommended: Pentium 4 processor (3.0GHz, or better), 1GB RAM, DirectX 9 level Graphics Card, Windows Vista/XP/2000, Mouse, Keyboard, Internet Connection

It runs just fine on my 1.7 GHz Centrino laptop with 1GB RAM and a Radeon Mobility 9700 128MB

I must agree that Portal is absolutely lovely. It's certainly the biggest innovation the FPS genre has seen since the late nineties. Every area that makes me dislike the Half-Life 2 series this game does just right: It's not repetitive (and short enough not to get tedious around the 2/3 mark). It genuinely explores the gameplay innovations that it brings instead of popping them in every couple of hours for novelty value). And best of all, it doesn't take itself too seriously (no 5-minute long cutscenes of talk, talk, talk). I can't remember the last time, that a game brought the feeling I had playing those simple but highly addictive games on C64 and Amiga - Gravity Force for instance, or even good old Arkanoid. Portal brought all that back, and despite being less ambitious and hyped than BioShock, I find Portal a much better game - one of the few that I consider playing more than once.

Oh, and the credit song must be among my favorite ever made for a video game (reminded me a bit of Magnetic Fields).

How did you try to rescale the character?

The easiest way by far would be to use Walkable Area scaling. If you use v. 2.72 or ealier, go to the Room Editor -> Areas -> Walkable areas and notice the box called Zoom level. Try entering 200% there (which is the max. by the way), then run the game to see if your character is large enough.

Edit: Of course you need to select the walkable area of the floor before setting the scaling.

I don't have time to participate in the playthrough, but I'll comment on a few things I remember from back when I played in on the Amiga (I bought the game just when it came out and still have it here on my shelf, although I don't like the packaging as much as the boxes of my Sierra and LucasArts games).

The graphics were lovely for their time. Especially the backgrounds and the wonderfully animated characters during dialogs. I loved the way you actually saw your character ask the questions instead, instead of just the NPCs responding. I remember that the vector graphics were impressive back then, but I'm not sure that they aged that well, though the animation was about the smoothest thing ever. The intro is still among the most atmospheric introductions to any game, and although slightly different in style, the vector-animated ending cutscene was something I played again and again.

My main issue with the game was - as other people have pointed out - the inconsistency of hotspots. But also the very awkward English translation. Who was the proof-reader? Hercule Poirot? The example that made the largest impression was probably the caption "Tomorrow morning" at the start of gameplay - I mean, unless the whole game is some kind of flash-forward, shouldn't it be "The next morning" or similar? Some of the hotspot names seemed obviously taken from a dictionary and could easily have been substituted with more everyday terms.

As this thread shows, the functionality of the editor's Colour Finder is slightly confusing. Now that the entire editor has been rewritten, wouldn't it be a good time to fix this dodgy behaviour? Especially as version 3.0 also introduces Game.GetColorFromRGB which doesn't have the issues that the Colur Finder does (for instance, Game.GetColorFromRGB(255, 255, 255) correctly returns 65535, whereas Colour Finder values (31, 31, 31) return 65503, which is in fact RGB(255, 250, 255)).

Edit: In response to Supspark, I couldn't care less about a color wheel - I just want my colors to be accurate and pure when I need them to be.

Actually in your case it would probably be better to develop the game in 320x240 resoltion and force 640x480 through winsetup.exe when testing/running the game. The current way you'll have to import scaled lo-res background artwork, and despite compression it may take up more space than true 320x240 images.

Would it be very difficult to make the color finder return the proper values? For instance, hardcode RGB(31,31,31) to return 15 instead of 65503, which, on a full 256-unit RGB scale is actually (255, 250, 255)? I did this for my own RGB color module (now obsoleted by Game.GetColorFromRGB), because I needed the colors to match the ones I used in PhotoShop.

Also, color 2143 (1, 1, 31) is actually (8,8,255), not (0,0,255) so for exact color picking, the advice to set red and green to 1 isn't really useful. In most cases the difference will not be discernible, but for instance I had to insert a logo sprite onto a white background on an in-game webpage, and the edges of the white logo background were definitely visible.

Edit: Sorry, didn't read above.

Happy to be of help in the making of this game. I hope you'll get a round to make an English language version sometime.

I know it's probably too late, but considering the focus on RawDraw and DynamicSprites in this edition, as well as the slowness of DynamicSprite.CreateFromScreenShot when using Direct3D mode, I have one last request:

Could we please have a DynamicSprite.CreateFromScreenShot function with the (optional int x, optional int y, optional int width, optional int height) parameters of DynamicSprite.CreateFromBackground? In Direct3D mode it's just no longer viable to create and then crop a DynamicSprite from the full screenshot every frame.

Edit: I realized that although it's a bit of a hassle to work around, I can achieve the same effect with other means (especially now that we can use DynamicSprite.Tint to make RawDrawn characters match the room lighting). The only actual problem is that the workarounds don't support walkbehinds. It would still be a very welcome feature, but it's something that can wait.

But I came up with another suggestion instead, which would be a nice addition, if it's trivial to implement:

DynamicSprite.Resize(int width, int height, optional bool antialias)

Which would implement the same antialising used for character scaling on the DynamicSprite.

* Added DynamicSprite.CopyTransparencyMask
* Added extra parameter to DynamicSprite.CreateFromExistingSprite to allow you to specify whether the alpha channel is copied or not
* Added COLOR_TRANSPARENT option to DrawingSurface.DrawingColor property to allow you to draw transparent areas onto the image

CJ, will you marry me?

How long did everyone take to learn Scripting? Curious I am.

If you get a week or two with nothing to do other than working on your game, you'll get a pretty good understanding of it in that time. Set yourself a goal, for example making a custom interface for your game, open up the help file and start coding it feature by feature.

The way I started out was with scripting my own save/restore interface. I hadn't coded anything since the days of BASIC on the Commodore 64 (oh god how I hated those "poke" commands),  I didn't even go through the AGS tutorials. I just sat down and  tried to break every function down into logical steps, one GUI element at a time. Whenever there was something I didn't know how to do, I used the help file's search function. Every time I would get a compile error (pretty much every line of code), I'd fix it, test the game to see that it worked as intended and then move on. A month into development I was coding advanced features that I'd never seen in AGS games before, such as the searchable conversation log.
Looking at my code now, there's lots of things I would have done differently (and I actually went back and optimized stuff and re-did some sections whenever new features - such as the String data type - were added to AGS). But the main thing is that the old code worked, despite sometimes getting the stuff done in very roundabout ways.

Once you understand the logic of AGS script, you'll be able to plan things out quite well even before opening up the script editor. And between the help file, the editor's auto-complete feature and the tech forum, there's very little that you won't be able to do - and do it much faster than using the Interaction Editor.

As CJ said, your shouldn't try too much too quickly, but at the same time, once you know the basics, spending a week on getting familiar with advanced features like structs, arrays and while loops will actually make things much easier further down the line.

Not being a Windows Vista user, I have another question regarding the setup program: Can Vista users somehow access winsetup.exe through the Games Explorer, or will they need to find the game's folder in the start menu like in XP?

Why give developers the ability to, for example, stop players from running 320x240 games in 640x480 mode? That's not a bonus, it's a guaranteed future headache. Save winsetup.exe!

I love how the people who want the ability to customize winsetup give perfectly realistic examples such as limiting a hi-res game from being run at half resolution (which in my case, due to the use of non-scaling fonts causes the custom linebreaking code to crash the game) - and those against will counter with some irrational example such as limiting lo-res games from running in hi-res (for the sake of argument, I could see a reason to at least block smooth scaling in such a case to keep a uniform style). Can't we just agree that some settings can be obviously "wrong" while others should be allowed for compatibility?

Incidentally, we already have this ability to limit these things - checking the resolution in game_start and preventing the game from running. But wouldn't it make more sense to not even give the player that option if it's not supported? I do think encrypting the .cfg file as suggested is being overly paranoid though, and it complicates reading/writing custom settings from in-game.

As far as I can tell, the ability to change settings seems to be used mostly to make games that wouldn't otherwise run do so, and in cases where the developer sends out the game with some incorrect default configurations. But apparently, this failsafe keeps some people up at night.

This certainly used to be the case, but with the introduction of the Direct3D engine, most people will benefit from using hardware accelleration while it may not be a good idea to have it as the default setting. So a lot of end-users will open up winsetup, see all the options and try to play around with them. Here the new filters are highly problematic as people have become accustomed from playing 3D games that higher resolution means higher quality, whereas in AGS it mainly means sluggish gameplay. I can easily imagine someone running a 640x480 game in 960x720 filtered, thinking they will get better graphics and in reality getting 320x200 with gigantic fonts and incredibly poor performance.

I argued all this in another thread but nobody seemed to get my point, so I'll just leave it at this.

Perhaps what is really required is some proper CJ-authored documentation of the file format in the Help file or elsewhere...

Yes, that would be highly appreciated.

You don't need to detect anything, just provide the same options to the player that the current Setup does.

I assumed that "digiwin=1096302880" and other values were device ids specific to the user's hardware. Are you saying that these numbers are always identical for the same listbox choice?

You can always write your own Setup program in visual basic or something and have it write the acsetup.cfg file as appropriate.

I tried doing this a while back (you may remember my suggestion to add the option of disabling "gamefile.exe --setup" functionality for the same reason), but ended up being stumped with the audio device detection code. I guess my best bet would be for someone skilled enough to write a fully functioning template that could be customized and compiled using a freely available tool like Visual Basic Express. Anyway, it won't be an issue for me for another 6 months at least, so I'll look further into it when I'm close to finishing my game.

You have to run it on the acwin.exe file before you compile the game; if you try to run it on the compiled exe file it won't work.

Ah, of course. I didn't try that - and it's even a much better solution in that you don't have to implement your changes every time you re-compile your game .

Not that I like to take apart CJ's lovely design of the winsetup, but I beleive ResHacker is the only way to do this right now.

All of my attempts to use ResHacker to change winsetup has resulted in corruption of the .exe file causing the game to refuse to run. Has anyone actually managed to do this?