Messages

Instead of using the built-in scrolling, call SetViewport from rep_exec to scroll the screen based on player character coordinates (or use the smooth scrolling module). That should keep it in sync as long as you update the NPC coordinates *after* you've moved the viewport.

I worked on a half-finished project with a similar effect and found some really good explanations of various pseudo-3D effects used in racing games on this website. Not sure it will help with your specific problem, but I found it very useful.

John Carpenter's Big Trouble in Little China and They Live - had forgotten it was Halloween, but it was appropriate viewing

What about this:
A is insane but with his medication, he stays calm.
B, who cares for A, notices that the pills have run out and drives to the pharmacy.
C is on his way to work in his car.
D runs across the street without looking, C swerves and crashes into B, A doesn't get his pills and goes onto a killing spree because E didn't lock his gun cabinet.
Who is responsible for the deaths?

D is responsible for any deaths directly resulting from the car crash, A's psychiatrist is partly responsible for the killing spree - and if A is a minor and E his parent, E carries part of the blame too.

Or if you're Michael Moore, the NRA gun lobby did it.

If you've already ruled out the shoe company getting the money back, as far as I'm concerned Mr. B keeps whatever was returned to him. His deal with Mr. A is closed, Mr. B fulfilled his part and whatever the gains from the clerical error is simply good karma from helping his friend out. Mr. A got his shoes and is no longer part of the equation.

This is mainly good news to me because I can never tell the two apart anyway - still not sure which one made Deathspank clone and who did Brütal Legend. Psychonauts was cool, but I'm not forgiving either of them for ruining the wonderful artform that adventure games could have been (and shall become - cue the revolution).

Phemar, avoid "Dexter in the Dark" like the plague. I haven't read the two others which are supposedly much better, but that third one was laughably bad.

I haven't had time to look at the source yet (have to reinstall Visual Studio first), but I think the room editor in particular needs careful coordination. Someone (ProgZ?) mentioned a wysiwyg'ish approach to see the effects of scaling and light settings on a character directly in the editor, which is a great idea. But it's also a good example of something that would have to be modularized enough that other engine plug-in coders could substitute their own room renderer, for instance to display 3D characters in the editor preview.

Most of my own ideas for the editor relate to engine plug-in functionality rather than enhancing the usability, but I'd be very happy to see the dialog editor redone to actually be helpful - I think there's was a plug-in or external dialog editor at some point, but I don't know what the status is on that.

True, the compiler would fail if I messed with the game.agf - so the editor would have to write image location and properties to a custom file instead. There'd still be an empty sprite file in the distribution folder, but that's pretty much it as far as compiler compatibility. Personally I don't really care about supporting the view editor if I have to write custom animation routines anyway (which would be for the better to avoid double caching), but of course some kind of integration with existing editor features would be necessary for a publicly released plugin.

It would ultimately have to end up in the same place anyway, in the same format, for the compiler to be able to make use of it. However, if the editor source were opened up then it would presumably be possible to write functions to handle that.

Not necessarily the same format (and certainly not the same place if you by that mean the default sprite .dat file). A plugin can easily draw images in different formats to the viewport from a virtual folder structure in a resource file. Possibly it would be necessary to use custom animation functions, though - I haven't looked that far into the plugin API.

The huge benefit that comes from accessing images from individual files stems not just for the ability to use different formats (e.g. photographic backgrounds in PGF and cartoon characters in PNG or even vector formats like SVG) to limit file size, or make editing of imported files easier, but also can help portability to other platforms. E.g. store your art in a very high resolution and zero compression and have it resized and compressed upon compile - a lower res version for iPhone and Flash, a medium resolution/quality for free download, and a printed DVD collector's edition with super-high resolution for fans with the hardware to run it. Or if you prefer having full control of scaling filters and touch-ups, store alternate versions in subfolders or using an amended file name which will then be prioritized upon compile for that resolution.

I should explain that what I wanted to do with my plugin was to make AGS totally resolution independent by replacing AGS' screen rendering and use a virtual resolution property instead of fixed pixel width/heights. So in the above examples, whatever the image size they would all stretch to the allocated screen space and placed on screen coordinates scaled accordingly. At the moment there's no way to intercept viewport initialization from a plugin, so we're stuck with the limited resolutions AGS currently offers, but as soon as that's possible it will all make sense - at least for the non-pixel-artists  .

The associations you're talking about actually are already kept in XML in the Game.agf file. IIRC even the relative paths from the import are stored in place of what CJ described as a future "update sprite from source" option (I believe).

Oh, I didn't realize this. I thought view, loop, frame assignations were part of the sprite .dat file for some reason. Then a custom resource file plugin along with an editor plugin to circumvent the sprite importer (and decode unsupported file formats to thumbnails) should do the job. Thanks for clarifying.

Is ags smart enough ...

AGS is smart enough to know that nobody else in the world gives a shit about which inventory item you picked up, or whether you just clicked a cow.

For example, the way it handles visuals right now can be time consuming.  (Is there a way AGS can utilize a directory(folder) with all the visual elements of the game while in production mode? Right now it keeps all sprites inside one file and are inaccessible outside of AGS for editing.)

Seconded to the Nth degree - would also make it much easier to provide plugin support for other file formats (e.g. lossy image compression). Associations between Views, sprite numbers and relative image paths could be kept in an xml file or similar.

Technocrat, I think you've just pitched the coolest game concept ever. "Murder Castle" - part Dungeon Keeper, part Hitman/Manhunt, and plenty of controversy to get media attention! 

I tend to prefer serial killers who are the protagonists of their stories - Dexter Morgan, Norman Bates, Peter Lorre's character in 'M'. But that's doesn't seem to be the style you're going for, so for antagonists - John Lithgow in the fourth season of Dexter and also as the 'Liberty Bell Killer' in 'Blow Out', and Dr. Gull in Alan Moore's 'From Hell' (the graphic novel, not the fucking movie bastardization). Also I recommend you check out 'Peeping Tom' and 'Jennifer Eight'.

To be honest, when I look at the changes I hope for, or even consider more or less necessary for AGS' continual growth as a tool and the engine's expansion onto other platforms, I'm beginning to wonder if that product would still be AGS in anything but name. The core design of the program is so firmly grounded in the adventure games of a certain era with rooms, characters, objects, hotspots, walkbehinds and so on, each with (sometimes arbitrary) limitations specific to their type. Of course stuff like this can be kept part of the default declarations to make transition easier, much like the current default GUI setup, but it would be shortsighted to treat them as anything but genre specific abstractions of a much more generalized system, and more importantly, to not allow user access to that base system.

My main reason for hanging on to a (hypothetical) future AGS rather than Wintermute 2.0 (whenever that comes out), or switching to a non-adventure specific engine, would be that I already know the scripting language. Yet thinking objectively, if the whole engine was rewritten wouldn't it make more sense to switch to an existing language like Lua or Python? Not only would it be easier for new user who already knew that language, but the skills learned while working in AGS could be transferred to professional game scripting. That kind of "universality" would also make it more attractive to use AGS in an education environment.

So I'm really on the fence here - on one hand I'm truly excited about the future of AGS as a community developed engine, and yet I'm in favor of changing pretty much every feature of it. At the same time can't help I wonder if there's any real consensus on a "vision", and I'mcurious what directions of development people have in mind.

In short, what do you perceive as the core of what makes AGS what it is?  And how elastic are the boundaries of that identity?

This thread makes me so happy to be on the AGS forums where people have good taste in games. If you had asked this question on adventuregamers.com or justadventure.com you'd have had ten people warmly recommending Post Mortem, Black Mirror and Still Life by now

I second Ascovel's suggestion of Shadow of the Comet. Not a perfect game by any means (i.e. you'll probably need to consult a walkthrough along the way), but the CD-ROM version is pretty damn atmospheric - and I love that the dialog portraits are based on classic horror actors like Vincent Price.

Another game worth checking out if you don't mind supernatural elements is Shadow of Destiny (aka Shadow of Memories). Feels like a console game, but the graphics are beautiful for their time and the story is very moving and full of mindbending twists.

It depends very much on the project - I rarely draw core story or gameplay concepts from music (happened in one case with a Bowie song and an unfinished MAGS game), but once I have some idea of the setting, themes and feel, I'll often listen to related music. For instance, if I'm making a game about computer hackers in 1980's Berlin (which incidentally I am), I'm bound to end up listening to Kraftwerk, or 'Heroes'-era Bowie.

For my game Shadowplay, I've often listened to Arcade Fire's 'The Well and the Lighthouse', and the Lou Reed album 'Magic and Loss', in particular the song 'Magician' (not album version). Also a recent favorite listen while writing is the Danger Mouse and Sparklehorse album 'Dark Night of the Soul' with a ton of guest artists including The Flaming Lips and David Lynch.

Edit: Music videos is a whole other matter though, they're like little seedpods of inspiration that explode in your mind and grow into beautiful forests. A few weeks ago I watched the video for OK Go's 'WTF' - right off the bat it inspired a very cool visual effect for one of my game projects, but then I started building on that idea and it grew into an entirely new kind of approach to adventure game GUIs! How awesome is it to get all that from watching a 3 minute video clip?

While I agree that a panel would be more or less necessary to keep "Future AGS" (aka FAGS) consistent and structure development in an efficient manner, I don't see any real benefit in limiting source access. What exactly is it you fear will happen if AGS goes completely open source? Paint a worst case scenario if you wish - and please do give examples if you know of any other game engines, 3D renderers etc. that have somehow suffered by going open source.

Edit: Yeah, what Calin said while I was writing this

If by any chance you have a time machine, my suggestion would be to travel 15 minutes into the past and check the READ FIRST *BEFORE* POSTING!!! thread.

If not, here's a list of All the Paint Programs You'll Ever Need!.