Question about point-and-click system for mystery VN

[pochi]

Hi,

I was just wondering if it is possible to click on a background and get some important objects/evidences, as well as show them to another character and hear them say something about it? Yes, I'm talking about the Phoenix Wright style because I'm making a mystery visual novel.

I looked at the previous posts in the forum and found some similar questions, but none of them answered what I was looking for. I even checked Attorney D and the Phoenix goes to Renpy games just to see if they have the investigation part, but they only showed the court scenes. T_T

Your help would be really helpful, thank you~

[The CRxTR]

Hello.

I hope it might be helpful...

I questioned in the forum about how to do image maps (very useful if you want custom interfaces w/o learning UI).

What you could do is using the combination of image maps and variables.

Firstly, you make a variable to the designated object.
Suppose if you have a ball object, you can state in the init in script.rpy:

init:
$ ball_pickup = 0
$ ball_given = ""

the ball_pickup variable is a boolean (true or false)
the ball_given variable is a stirng ("Dude" for eg surrounding in doublequotes is the string.)

You then do an img map with hotspots on the objects you wanted, for example you made a jpg on a background with a table and a ball.
You can then enable the pickup:

Code: Select all

$ ball_pickup = 1

This signifies that you picked up the ball.

Finally, If you want to share to others the ball or giving it to others:
eg:

Code: Select all

e "Hey, what do you have there?"
me "I have a ball, do you want to take it?"
if ball_pickup == 1:
     $ ball_given = "e" # this can be the name of the character or the equivalent
else:
     e "You don't have any ball"

If you want to know how to do these image maps:

You may also want to check this...
http://lemmasoft.renai.us/forums/viewto ... 168#p78168

"POOF" (Disappears)

Again hope this helps. ; )

[Wintermoon]

Suppose if you have a ball object, you can state in the init in script.rpy:

init:
$ ball_pickup = 0
$ ball_given = ""

If you're going to modify your variables later, it's better to initialize them under 'start', not 'init'. 'init' is for variables that stay constant throughout the game.

[The CRxTR]

The CRxTR wrote:Suppose if you have a ball object, you can state in the init in script.rpy:

init:
$ ball_pickup = 0
$ ball_given = ""



If you're going to modify your variables later, it's better to initialize them under 'start', not 'init'. 'init' is for variables that stay constant throughout the game.

Well, it's just like "Dim" in Visual BASIC (fro those who don't program, 'dim' declares the variable like 'python' or '$', you usually declare 'dim' in the 'General Declarations' section, in this case "init".)

So that the variable can be used all over the game.

For example if the ball object is used on the whole game, it is nice to make a variable in a beginning of the program.

Sorry for the argument.

But the image map works on his situation right?

[killdream]

The CRxTR wrote:Suppose if you have a ball object, you can state in the init in script.rpy:

init:
$ ball_pickup = 0
$ ball_given = ""



If you're going to modify your variables later, it's better to initialize them under 'start', not 'init'. 'init' is for variables that stay constant throughout the game.

Well, it's just like "Dim" in Visual BASIC (fro those who don't program, 'dim' declares the variable like 'python' or '$', you usually declare 'dim' in the 'General Declarations' section, in this case "init".)

So that the variable can be used all over the game.

For example if the ball object is used on the whole game, it is nice to make a variable in a beginning of the program.

Hm, well... it's a no and sort-of-no. All variables you declare in Ren'Py will go on the global namespace by default and will be shared through all files, unless you declare it inside a function or class, it is. The init section has the purpose of initializing things before the game runs, and when the player loads the game Ren'Py will just apply the modifications to these variables as needed. And anyways, in Python whenever you assign a variable to a value it'll be defined for you (if it had not been defined yet).

You can declare variables in-game (the start or whatever label), but then you can't make sure that Ren'Py will set those variables before you request them, and your game can end up with a "Variable x is not defined.". And you'll most probably have problems with loading a game after modifying the script to use that variable before it's defined on the save file.

[Wintermoon]

Well, it's just like "Dim" in Visual BASIC (fro those who don't program, 'dim' declares the variable like 'python' or '$', you usually declare 'dim' in the 'General Declarations' section, in this case "init".)

'init' isn't anything like a 'General Declarations' section. Variables assigned in 'init' are supposed to be constant, so Ren'Py won't try to save them when you save the game. This is good for characters, which Ren'Py can't save. It's bad for integers that you intend to change later.

(IIRC Ren'Py does have a mechanism for detecting changes to variables assigned in 'init', but it's not perfect. It'll catch changes to integers, but not changes to the contents of lists, for example.)

The other problem is that 'init' is run exactly once when the program starts. So if you set the variable to 0 in 'init', play the game until you reach the point where the variable is set to 1, quit to the main menu, and start the game again, you will now be playing from the start with the variable set to 1. The only way Ren'Py can avoid this is by having two copies of the variable, one set in 'init' and the other set in the actual game. (I'm not sure if Ren'Py does this, but I doubt it.)

[killdream]

(IIRC Ren'Py does have a mechanism for detecting changes to variables assigned in 'init', but it's not perfect. It'll catch changes to integers, but not changes to the contents of lists, for example.)

Well, it is for what it proposes to do. It'll catch and save all REFERENCE changes. For example, assigning an integer to a variable will cause a reference change.

Code: Select all

$ my_var = 0

While just popping or appending to a list will not, therefore if you write just:

Code: Select all

$ my_var = [] # this will be saved
$ my_var.append(1) # this will not be saved

So, to avoid those problems you'll just need to change the reference for the object. Which can be done by making a deep copy of them.

For a list, something like:

Code: Select all

$ my_var = [] # this will be saved
$ my_var.append(1) # this will not be saved
$ my_var = my_var[:] # this will be saved

Should do.

The other problem is that 'init' is run exactly once when the program starts. So if you set the variable to 0 in 'init', play the game until you reach the point where the variable is set to 1, quit to the main menu, and start the game again, you will now be playing from the start with the variable set to 1. The only way Ren'Py can avoid this is by having two copies of the variable, one set in 'init' and the other set in the actual game. (I'm not sure if Ren'Py does this, but I doubt it.)

I'm not sure of that. I guess contexts exist so each time you start a new game a new variable context will be started with the values defined on init. But again, I'm not sure about this, but it does makes more sense this way.

[Wintermoon]

Well, it is for what it proposes to do. It'll catch and save all REFERENCE changes. For example, assigning an integer to a variable will cause a reference change.

The rules are clear and easy to remember when you know them, but it's still a hack. There's a right way and a wrong way to program, and initializing variables that you intend to modify later under 'init' is the wrong way, even if it works.

[Showsni]

So, yeah, to get back on topic image maps are what you want to use.

http://www.renpy.org/wiki/renpy/doc/ref ... y.imagemap

[The CRxTR]

Thanks for the corrections guys.
Good thing this is only my hobby. I'm no expert at programming though.

These guys are right on one thing or another.
But still the decision is on you.

(I don't know what I'm saying I have fever....)

I hope that we helped one way or another.

[The CRxTR]

HELLOOO AGAIN

My fever subsided and I'm back with a question....

(This post is perfect for this cuz it's related here.)

I answered his question by saying...

What you could do is using the combination of image maps and variables.

and of course a lot of you guys questioned my reply.
and now I question a similar one too....

I'm making this game called "Romance on Sunset Boulevard" and I've been using the "init" block to initialize a variable to be used for the name of the protagonist (Using DynamicCharacter as the character protagonist).

Code: Select all

init:
     $ ego_name = ""
     $ ego = DynamicCharacter('%(ego_name)s')

Can I have other alternatives aside using the "init" block?

[Wintermoon]

Code: Select all

init:
     $ ego_name = ""
     $ ego = DynamicCharacter('%(ego_name)s')

Can I have other alternatives aside using the "init" block?

Code: Select all

init:
     $ ego = DynamicCharacter('%(ego_name)s')
label start:
     $ ego_name = ""

ego is a character and does not change, so it goes under init. ego_name is a string that presumably changes during the game, so put in in your actual script. Better yet, wait until you have an actual value for ego_name before initializing it.

Note that you don't have to initialize ego_name before ego, so long as ego_name exists when you actually use ego.

[The CRxTR]

@ Wintermoon:

What do you mean;

Better yet, wait until you have an actual value for ego_name before initializing it.

And thanks in advance.

[Wintermoon]

Presumably you have some place in your script where ego_name is assigned a real name instead of the empty string (""). Unless you want to use the ego character before that point, it's OK to skip the initialization to the empty string.

So if you have something like this:

Code: Select all

init:
     $ ego = DynamicCharacter('%(ego_name)s')
label start:
     $ ego_name = ""
     "Please enter your name"
     $ ego_name = ui.input()

It's OK to simplify to this:

Code: Select all

init:
     $ ego = DynamicCharacter('%(ego_name)s')
label start:
     "Please enter your name"
     $ ego_name = ui.input()

[JinzouTamashii]

I have a conceptual question. In a regular VN, will the user be expecting suddenly imagemaps in the background? Should they be animated or otherwise have an eyecatch?

I mean, it should be obvious, right? If it's going to have a location menu like Divi Dead, and also a hunt-the-object to go with your mystery ... I've never tried the DSE yet, but I know what it's about in theory.