Messages

I just noticed, is this ok that locked threads are positioned not in the order of the last post's date, but beyond all the non-locked threads?

Not to argue Tabata's command, but one question regarding gameplay: is there a general time limit for user input before next in-game event happen, or this "timer" is used only in certain critical situations?

That depends on how long is the way to go...

But I prefer Click.

[player character is not player]

First of all, I consider first two options the same, or second an extended version of the first. Therefore I do not make difference between them.
Secondly, I think that the other (third) option is "vague" only when (because) game designers make it so.

It's difficult to make a perfect categories, but I think there are different three choices:
1. Literal options: character starts the response with the exact replica you chosen. Sometimes it is the only thing he sais. Sometimes he may add a thing or two.
2. Descriptive options: give you a description of how character should behave further.
3. Topics. Gives a list of subjects (events, characters, inventory items etc) that could be discussed. PC may not say anything, it could be assumed that PC asked "what can you tell about X".

In my opinion the choice for the dialog is a part of game design and, as game design in general, does not have answer for all cases.

I may figure that if the game has dialog puzzles, it might be necessary to allow player choose from literal choices, otherwise it will not make much sense.
For purely detective games Topics could be best.
I could argue with "Descriptive" option (or "Vague" in your classification) to be most unimmersing. I can see your point, but for times too many I could not find a line I'd really liked character to say among given "verbatim" choices; and felt like the game forced me to choose something I did not want to. What should be remembered is that, unlike RPG with fully-customizable characters, in adventure games player character is not player. He may think different from player, behave different from player. Therefore the "detachement" from character may be an important feature of game design. It emphasises the distance between player and game world, allowing player to observe the story, like he observes the novel or a movie. In my opinion that allows to give character more depth. When under total controls from player, character may seem not very individualistic, especially when player makes him say something that does not match character's personality.
That's why I'd choose "Descriptive" (or "Vague") dialog style for drama genre.
Meanwhile "Literal" (or "Verbatim") style could fit the comedy genre more, because (amongst other reasons) it may allow the player to "play" the jokes himself (if he will be smart enough).

What was Ponch's first word?

"Moooma!"

Baron, change your game dev company name to "Lustful Adventures". You'll surely get more customers.

Took me some time to realize this is solved by topic starter
Slasher, please, if you found the solution, change topic title by adding [SOLVED] prefix.
Also, just a recommendation - put EDIT at the end of your post rather that in the middle. This is too confusing!

What is your laptop's display resolution?

Usually this error means you cannot run the game in fullscreen with that resolution. Try running in window.

Really? The reason why you can work on AGS is because it's open source. And you think about how to make it closed again because of this? Also, what do you want to achieve? Your plans went from improving encryption to writing a decompiler and back in this thread, so why care at all?

I never planned on improving encryption. In fact, one of my first questions was "In this situation is there any sense in data encryption?". I was thinking about completely removing it for future versions, exactly because there's no sense in this now.
My plans never went back and forth, I had no certain plans in regard to encryption yet. In this thread I was trying to know other ppl opinion on this.
And I don't know how you came to a thought I want to close AGS's source. I stated that game devs could make their own copy and make it closed. Probably.

My question is, and it's not rhetorical, what would be the real danger in having these games be decompilable? Is there really a genuine widespread fear of others stealing art assets?

Perhaps real game devs should answer this; I myself don't have such fear, but I just have certain care about game devs who may have their own opinion on this .

How hard would it be to make an AGS compiler/utility that could be triggered by a PHP script or somesuch on a web server to make a unique version of the game encrypted with a unique key, which needed to be set up at install time. It wouldn't stop people from copying, but at least you'd know whose copy the copying came from.

Earlier I stated that: it is enterely possible to take engine source and change it so that it will produce totally unique encryption/decryption for this certain game you are making (or number of games you are making).
Now when I read the Artistic License more closely I am not really sure that you may disclose the source from the end-users.
It sais that:

You may Distribute a Modified Version in Compiled form without the Source, provided that you comply with Section 4 with respect to the Source of the Modified Version.

Section 4 states that:

You may Distribute your Modified Version as Source provided that you clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, and provided that you do at least ONE of the following:

And one of "the following" is:

make the Modified Version available to the Copyright Holder of the Standard Version, under the Original License, so that the Copyright Holder may include your modifications in the Standard Version.

or

ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the Modified Version must bear a name that is different from the name of the Standard Version.

So, basically, does that mean that the person can keep his source closed from anyone except original author, or closed from everyone if it does not counterfere with "standard" installation?

If yes, then that method may have certain sense, but it will have certain drawbacks:
1. A game dev should care about hacking the compiler and engine, as well as updating it with latest official changes on his own.
2. The AGS team (ones that work on developing the engine) will not longer be able to effectively support the engine that runs this game, since the code is different and there's no guarantee the author of the changes did not break anything himself.

I must restrain... err, refrain then.

I was thinking that it is possible to make a stand-alone browser utility to see what's inside the game.
I mean, it should be legal, but how... umm... ethical.

Well, that was my point too, that it will be practically impossible to keep the data from being ripped anyway.
But here goes the second question: won't that scare off commercial game developers?

One thing is making a screenshot with characters/guis/cursor over background, another thing is extracting resources in their original state.

Since the AGS source code is open, there's no problem in writing a data decompiler. Probably it is possible to restore the project to the point where you can extract all the in-game resources (except original filenames of the imported material).

In this situation is there any sense in data encryption?
Does everyone realize that every game made before source is opened may be now decompiled?
May that prevent some people from using AGS in the future?
( Am I doing a wrong thing telling this to everyone?  )

Thinking further on encryption, I see only one way to make it more useful - is to change the encryption key in the data compiler/engine for each specific game. IDK how difficult that would be for experienced hackers to find an address of the key in default engine executable and then deduce its address and value in game's one. Maybe not so, unless the code has more changes, or compiled with different settings etc.
Any thoughts on this?

what im trying to do is a light effect.
so at game start the room flashes, flickers a couple a times like a fluorescent light is being turned on.

Try to put this in your "Room After Fade In" function:

Code: ags

FadeOut(64);
Wait(10);
FadeIn(64);
Wait(10);
FadeOut(64);
Wait(10);
FadeIn(64);

Will that do similar thing to what you want?

Hmm, do I understand correct that you want to make verything pitch black for a moment?
Have you considered using FadeIn/FadeOut functions:
http://www.adventuregamestudio.co.uk/wiki/?title=Screen_functions#FadeIn

May they fit your needs?

E: Oh, wait. You mean there's nothing but doors visible?
Then they probably won't be that useful....

What about a big black object in foreground with "holes" for doors?

Your second curly bracket is wrong: you use opening one '{', while you should use closing one '}'

There's no such variable as inv6 in character class. You mean "inv" array, in which case you access its elements by index, putting the index in square brackets like

Code: ags

cDave.inv[6];

I do not know which version of AGS you are using, but in the recent version "inv" is considered obsolete. If you are using AGS 3.+, I'd recommend to use one of the following:
Use either Character.HasInventory function (if you do not need to know exact quantity, just the fact of presence)

Code: ags

cDave.HasInventory(iInventoryName);

or Character.InventoryQuantity[] array (the exact substitute for "inv"):

Code: ags

cDave.InventoryQuantity[6];

The attaching works because the data file has a file header at the end of it that indicates its length. So it can always find the real header regardless of where it is attached (IIRC).

Small correction: engine first checks the data signature at the beginning of the file. If there's none, it checks the end, assuming it might be executable with data attached.

E: Not sure how useful this is though. Especially Linux is tricky because of the different flavours that all have different library versions.

Yes, right. I keep forgetting about that.

Perhaps there's a sense in just building game data separately without windows exe?

I actually wonder will that work if you substitute the acwin.exe in AGS editor's folder with e.g. linux executable. Will the editor succeed in attaching data to it? And will the resulting executable run?
I guess it is easy to try out. If that may work, we may actually add extended compilation options to editor, like "compile for linux" etc, which make it select different executable corresponding to target platform.
You won't be able to debug that from editor, ofcourse. You will have to run Windows version for debugging anyway.