Handling objects in a point-and-click system?
Hi, in honor to the good old LucasArts adventure games like "Monkey Island" or "ZakMcKracken", the first chapter of my "Ingoverse" will be a point-and-click scene like those classics above, but still in 3D. I got about 60 interactable objects in the scene and 15 action-buttons to interact with them. Already makes a total of 900 possibilities. Most of them just result in a text above the player's head, but some interact with other objects, depending on their actual state. Like "Use DVD with DVD player -> has player got DVD? -> Is DVD player on' -> is TV switched on?"...
Since every object has to react different from the others, I created a cascade of branches checking all those 15 possibilities one after the other, what results in huge blueprint code only for one object.
There must be a better way to handle this, maybe using arrays, structures and such. I already watched some inverntory-tutorials, the one from Titanic Games I'll choose when the player is back to "real 3D", but all of those didn't really match to my game. Maybe someone here can point me to the right direction or maybe my code is just fine as it is and I have to blow up my Level Bueprint further.
Here's a video describing what I'm talking about. I create the game in my native language to get the best out of my fantasy, but I'll add an english version as soon as chapter one is done. ;)
I think you have this problem because you're trying to do the whole thing in the level BP?
You need to find out about Blueprint Interfaces!:
They allow you to make BPs clickable, but the code about what to do lives in the BP, so you can cope with all your possibilities without trouble :)
answered Aug 13 '19 at 10:45 AM
I agree with SebaSopp:
The way I think about it is:
1) You create one or more places that contain booleans for states of the game that need to be known by more than one object. Where you put those booleans depends a bit on the design of your game. If you only had one level (room) as described above, GameInstance would work fine for all of them. It is global and easy enough to find when you need to check a boolean state variable (bIsLightOn, bIsDvdPlayerPossessed etc). If you have more than one level then you might want to put the boolean state variables that do NOT carry over from level to level in GameMode and then each level can have its own unique version of GameMode. The boolean state variables that DO carry over from level to level (like inventory) can be in GameInstance or in the Character
2) The Character's job is to execute the"Move To" command and then, having moved to an object, which is then the object "in focus", interact with that object. This is where the BluePrintInterface comes into play. You make a standard way of interacting with any object, for example you create an interface called "Interact" and send with that interaction an input that indicates the type of interaction based on one of the 14 buttons (other than Move To) that was pressed. This means the input to "Interact" would be the object you interacted with (an object that would implement the interface) and a message variable
3) Each button, when selected, would provide the contents for the message variable as an output so that the interface could pass it to the object being interacted with.
4) Each object then implements that interface by reading the message, checking boolean state variables stored by itself, those stored in GameInstance and/or those stored in GameMode or the Character and then decide what to do (including changing any state variables that it owns that are stored in those locations).
The main benefit of this approach is that you don't have to centrally figure out with a giant "if" structure which commands to call, the basic flow is (loosely in pseudocode):
Character::MoveTo Command determines which object is "in focus"
Button::Message variable provides a message as to which interaction button was pressed
Character calls InFocusObject->Interact(Message) to send the message to the Object In Focus. This identical call would be made to any in-focused object, all of the inputs are variables (InFocusObject, Message) so one line of code (in the blueprint sense of the word "line") does it all for any object. As written, the code doesn't "know" which object is in focus until the program is actually running.
Each object receives the message, checks boolean state variables and decides what to do including perhaps doing nothing.
If all that happens is a message needs to be flashed over the character, you can have a similar "message" strategy where the object being interacted with fires a "display message" event at the character and sends the message to display.
Follow this question
Once you sign in you will be able to subscribe for any updates here