Expect this forum to be filled with questions about mouse controls because of James's contest.
Anyways, I was wondering what the best way to detect clickable areas would be for HUD commands and objects. The game layout HUD itself is something I put into the tile editor. Should I go by X,Y coordinates, use NPCs, zones, something else?
Best method of assigning clickable areas?
Moderators: marionline, SDHawk
My post in question: http://www.slimesalad.com/forum/viewtop ... 219#116219. But I assumed kylekrack mostly knows what he's doing; hardly a start on a real guide.
BTW, if you use the mouse I highly recommend increasing the framerate to 60 fps (an option in recent nightlies).
BTW, if you use the mouse I highly recommend increasing the framerate to 60 fps (an option in recent nightlies).
Sounds like a good idea! I hadn't thought about that. Is there an option in the editor for setting the framerate permanently in game or do you have to do it manually while playing like before?TMC wrote:BTW, if you use the mouse I highly recommend increasing the framerate to 60 fps (an option in recent nightlies).
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Well. Here's a related question to my original one, as far as design approach goes:
Is it a good idea to use the 20x20 grid for placing clickable slices or is assigning arbitrary X,Y placements easy enough to where it doesn't matter? I was thinking of resizing and shifting the inventory/spell menu box so it neatly fits 20x20 walkabout NPCs. But it'd be a pain and might mess up my current screen real estate setup.
Is it a good idea to use the 20x20 grid for placing clickable slices or is assigning arbitrary X,Y placements easy enough to where it doesn't matter? I was thinking of resizing and shifting the inventory/spell menu box so it neatly fits 20x20 walkabout NPCs. But it'd be a pain and might mess up my current screen real estate setup.
I wouldn't use the 20x20 grid for clickable slices, simply because it limits a lot of what you can do. It's pretty simple to do it on a pixel basis, and that way you have more freedoms, and you can make clickable boxes smaller than 20x20. In addition to that, slices don't always work smoothly with the grid, since they are drawn above it and not aligned with it in any way by default.
What you could do is make a grid slice in the slice collection editor and make the rest of the slices children to that. That way you could set the columns and rows to whatever you want, still giving you a grid, but this way you can customize the size of them, because 20x20 might be the wrong size, or get in the way of the HUD, etc.
What you could do is make a grid slice in the slice collection editor and make the rest of the slices children to that. That way you could set the columns and rows to whatever you want, still giving you a grid, but this way you can customize the size of them, because 20x20 might be the wrong size, or get in the way of the HUD, etc.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
If you download the latest nightly, it's a setting under General Game Data.kylekrack wrote:Sounds like a good idea! I hadn't thought about that. Is there an option in the editor for setting the framerate permanently in game or do you have to do it manually while playing like before?TMC wrote:BTW, if you use the mouse I highly recommend increasing the framerate to 60 fps (an option in recent nightlies).
w00t ok thanks
EDIT: Oh my god it's so smooooooth
EDIT: Oh my god it's so smooooooth
Last edited by kylekrack on Thu May 28, 2015 5:58 am, edited 1 time in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
As far as approach goes: Would it be a wise idea to put all the omnipresent clickables on the HUD (like the LOOK, TAKE, etc. commands) into a slice collection and give them unique lookup codes and basically go from there?
And then related to that, would making a different slice collection with every interactable background item per scene/room be a good approach as well?
This is where the whole "uh how do you do a mouse game" trepidation comes from for me, I don't know how to approach it in a way that's efficient. Also if there's a better way to go about this, please let me know. I can draw pixels and come up with level designs but dealing with slices is something I never got ahold of.
And then related to that, would making a different slice collection with every interactable background item per scene/room be a good approach as well?
This is where the whole "uh how do you do a mouse game" trepidation comes from for me, I don't know how to approach it in a way that's efficient. Also if there's a better way to go about this, please let me know. I can draw pixels and come up with level designs but dealing with slices is something I never got ahold of.
A bunch of slice collections for each room seems like a reasonable way to do it and I've done it that way before. My script basically boiled down to three parts:
Part 0: A while loop that updated the graphical position of the mouse.
Part 1: A thing in Part 0 that checked to see when you'd clicked.
Part 2: A thing called by Part 1 to see what Phase of the Game it was, and find out if anything interesting should happen because you had clicked.
Part 3: A thing called by Part 2 if you'd clicked on something interesting to make that interesting stuff happen.
Part 4: The actual interesting stuff that happens.
Probably just going to confuse you (I've already confused myself, I have no idea what I was smoking when I did this) but here's some snippets from the code for Typewriter 3 that I've tried to clean up for clarity:
The only really tricky part to that is the RunScriptByID in IsCursorOn. You can type an @ before a script's name to get its numerical value rather than its textual value, so you can use it as an argument in another script.
The "best" way to do it is the way that you're going to be comfortable with. I was tired of typing and "automated" it a little with that script (I think I must've had help from someone, I can't imagine thinking of that on my own) but I could've just as easily typed a hell of a lot of "If (SliceCollide (THIS)) do (THAT, THAT, SOMETHING ELSE, ETC.)" and indeed, I've done it that way before too.
The important thing to remember for a game like this is that you're going to be doing a LOT of menus and items and rooms and clicking and you're going to want to try to organize it in a way that you're going to be comfortable with for the long haul. If it's a system some nut suggests to you on a forum, you might have a hard time dealing with in the long run vs. something you'd done for yourself.
Part 0: A while loop that updated the graphical position of the mouse.
Part 1: A thing in Part 0 that checked to see when you'd clicked.
Part 2: A thing called by Part 1 to see what Phase of the Game it was, and find out if anything interesting should happen because you had clicked.
Part 3: A thing called by Part 2 if you'd clicked on something interesting to make that interesting stuff happen.
Part 4: The actual interesting stuff that happens.
Probably just going to confuse you (I've already confused myself, I have no idea what I was smoking when I did this) but here's some snippets from the code for Typewriter 3 that I've tried to clean up for clarity:
Code: Select all
#########
#Part 1: This was in a while loop...
if (MouseClick (LeftButton) )
then (
MouseCheck
)
###################
#Part 2:
script,MouseCheck,begin
#If this script is running, the player has already clicked. Find out if that means anything
IsCursorOn (lookupslice(Sli:ButtonSaveDocument),@ClickDoSaveDocumentButton)
IsCursorOn (lookupslice(Sli:ButtonNewDocument),@ClickDoNewDocumentButton)
IsCursorOn (lookupslice(Sli:ButtonLoadDocument),@ClickDoLoadDocumentButton)
end
#########
#Part 3: This kept me from having to type "If (SliceCollide) a million times and made it really really easy to automate.
script,IsCursorOn,WhatTarget,WhatDo,begin
#What Target refers to a slice that the mouse might be on.
#What do is one of those @ScriptName thingies
if (SliceCollide (Cursor,WhatTarget))
then (
runscriptbyid (WhatDo)
exitreturning (true)
)
else (
exit returning (false)
)
end
########
#Part Four: This is the stuff that happened once it found out what button you'd clicked.
script,ClickDoSaveDocumentButton,begin
showtextbox (1)
waitfortextbox
end
script,ClickDoNewDocumentButton,begin
showtextbox (2)
waitfortextbox
end
script,ClickDoLoadDocumentButton,begin
showtextbox (3)
waitfortextbox
end
The "best" way to do it is the way that you're going to be comfortable with. I was tired of typing and "automated" it a little with that script (I think I must've had help from someone, I can't imagine thinking of that on my own) but I could've just as easily typed a hell of a lot of "If (SliceCollide (THIS)) do (THAT, THAT, SOMETHING ELSE, ETC.)" and indeed, I've done it that way before too.
The important thing to remember for a game like this is that you're going to be doing a LOT of menus and items and rooms and clicking and you're going to want to try to organize it in a way that you're going to be comfortable with for the long haul. If it's a system some nut suggests to you on a forum, you might have a hard time dealing with in the long run vs. something you'd done for yourself.
As I said elsewhere there are a lot of different ways to accomplish something, including plenty of ways that are just as good as one another. If you just start with any way of doing it, and then make incremental improvements, like moving duplicated code into a separate script ("local optimisation"/"hill climbing") you'll end with something pretty good.
Having one slice collection per room, and another slice collection for the fixed UI, with unique lookup codes for each clickable thing is good, I don't know a better way.
I would not use "slide collide(slice, mouse cursor slice)" as Giz does in that script. That will result in being able to click on something when you're actually pointing just off the edge of it, because the mouse cursor is partially over it. Instead use "slice collide point", as in the script I gave in the other thread.
Having one slice collection per room, and another slice collection for the fixed UI, with unique lookup codes for each clickable thing is good, I don't know a better way.
I would not use "slide collide(slice, mouse cursor slice)" as Giz does in that script. That will result in being able to click on something when you're actually pointing just off the edge of it, because the mouse cursor is partially over it. Instead use "slice collide point", as in the script I gave in the other thread.
Ok so I had an idea that I think I'm going to employ in my own game. For the different screens that have a GUI, such as the title screen, menu screen, and inventory, I'm going to make a separate keypress handler script for each one. So, when you open the menu, the command 'teleport to map(...)' is called, and that map has a keypress script that will only look for the player clicking on the things available in the menu. I think this will make it much easier to limit what the player can do while the game is "paused" and can't keep clicking on things while other menus are open.
EDIT: Giz, I did the same thing with a 2x2 box at the tip of my cursor. I thought I was being creative.
EDIT: Giz, I did the same thing with a 2x2 box at the tip of my cursor. I thought I was being creative.
Last edited by kylekrack on Sat May 30, 2015 4:54 pm, edited 1 time in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
I have to say, the plotdict.xml stuff for "find colliding slice" is really confusing. I was thinking that finding a colliding slice under the mouse cursor x/y, getting its handle and returning that to another script would be a good approach but what does this command even actually do? The first sentence says it searches through all descendants... which is cool I guess... but does this command return a value, or does it do something else?