TheGameCreators / GameGuruRepo

The GameGuru Repository For Community Collaboration
http://www.game-guru.com
137 stars 56 forks source link

GameGuru MAX - Ease of Use Request - Hooking Up Keys (and Other Things) #1690

Open MonkeyFrogStudio opened 2 years ago

MonkeyFrogStudio commented 2 years ago

Currently, when we activate Shooter, we can hook a particular Key to a particular Door via connecting them one to the other. This is a great visual way of doing things. However, it quickly breaks down if the key and door are far apart, such as the key is on the opposite side of a very large level from the door (especially with MAX supporting very large terrain areas now). It would be virtually impossible to drag from the ball over the key to the ball over the door across an entire terrain map to connect a key to a door. So, this method would only work for keys that are in close approximation to doors ... and then, what's the point? The player only needs to pick up the key that almost right next to the door. What fun is that?

This means we need a different way of doing this, I think. Here are a few suggestions:

True Prefabs

This would be the most complex system from your side programmatically. But having an actual, honest prefab system would solve this. With a prefab system, the end-user could visually connect a key to a door, but the door and key could be placed anywhere individually. They wouldn't have to be "physically" together unless the end-user wanted it that way. Of course, there's a lot more that a prefab system has to offer, but this is a part. I also understand that this may be beyond the scope of MAX (at least at the moment). Even so, I offer it as a potential solution. If you're not clear on what a prefab is from a game editor perspective, please ask and I can provide some links, etc.

Type Entity Name in Behavior Area

Another solution that seems like it would be simple would be to simply allow the end-user to type an entity name into the behavior area to accomplish this. To do this, it would be simplest, I think, to create a Key behavior and a Door behavior. The end-user attaches the Key behavior to their key and the Door behavior to their door. Each behavior should have a Name field. The end-user can then enter a name to make the behavior unique. Thus, a key could be named "Red Key" and a door "Red Door". The end-user could select the door with the Door behavior and go to a Locked? area, which should have a Name field. There, the end-user enters the Key behavior name. In the case of the Red Door, they would enter Red Key, ensuring that only the entity with the Key Behavior with the name Red Key would unlock that particular door entity.

Drag from Current Object Area

Another possible solution (again, don't know how complex this would be to program) would be to drag an entity from the Current Objects area and drop it onto another object to create a "relationship". There could be a special key that would need to be pressed or a special mode the end-user would need to be in or something to tell MAX that the end-user is not trying to place the entity in the level, but is attempting to build a relationship between the dragged entity and the one being dragged onto.

With this, the player moves in the viewport to the door, for example. Then they find the key in the Current Objects area to the bottom-left of the MAX UI. They then enter the "pairing" mode, click-and-drag the key onto the door, and the key is now associated with that door to unlock it.

With a method like this, the key and door could have already been placed in the level wherever the end-user wanted, as near or as far apart as they pleased. You could even set this up so that entering "pairing" mode (or whatever you'd call it) would automatically ask for what behavior to apply, etc.

END

In any case, that's a few ideas. I hope this helps in some ways to get you guys thinking about how to overcome this issue and make MAX even more awesome.

Kitakazi commented 2 years ago

Also with the behaviors there is currently no way to have a locked door open via a switch. Which could be fixed by adding the "ifused=" field or Entity Name as you suggested.

MonkeyFrogStudio commented 2 years ago

Actually, there is a way to lock/unlock a door via a switch with current behaviors. You set the current door behavior to locked, link your switch to it, then click the "brain" icon between the two linked items. At the top of the right-hand panel you should see an area labeled, "Shooter Connections". There, you'll find Object and Object with a drop down menu. Use the menu and select Toggle other object. This will toggle the door from locked to unlocked.

Unfortunately, this is limited. It will lock/unlock the door, but I've not found a way to open/close a door via a switch or a pressure plate ... yet.

MonkeyFrogStudio commented 2 years ago

From the questions and answers of the latest live broadcast (#75):

Q> Any ideas what you will do to fix the current linking of keys and doors if they are at different ends of the map? A> That is a great point. We are looking to improve the visual logic on connecting objects, but connecting them at distance is not currently in our design. The easiest way is to connect them first, then drag the object to your destination. It could be our planned improvement will allow connecting objects at extreme distances, watch this space!

Connecting first and then dragging objects to their desired destination is not always a good solution. In fact, it can be a downright PITA in some instances. Let's say that you want the key to be at one end of your large map and the door at the other. Do you really expect the end-user to place them near each other, make the connection, and then drag the door across the map, sliding the door, moving the viewport, sliding the door, moving the viewport, sliding the door, moving the viewport, until they finally get to the other end of the map? And if the door was made to precisely fit into a section of the map, the end-user has to go about doing that now, too. This may the the current "easiest" solution, but it is definitely not the best solution to this issue.

UltraVox001 commented 2 years ago

It would probably be ideal to use the current Game Storyboard method to tie things together. Would a "Light Storyboard" be possible? In practice, a "light storyboard" appears like that of the Game Storyboard, but which allows the lights to be linked to switches, etc.

It would be an interesting method and it would offer great possibilities. In fact, the current visual system is efficient at linking things close together. But once you have linked all the lights in a building, it becomes difficult to see clearly, because everything gets mixed up. And there are no filters to limit the display (eg I would like to see what is related with this switch, but not the others). And when the two points to be linked are too far apart, or when they are separated by obstacles, it is a real waste of time.

MonkeyFrogStudio commented 2 years ago

I don't see how a storyboard would be used for things like switches and keys, etc. These are game elements and there are potentially just too many of them for this to be practical. There needs to be a way to hook them up in-level.

UltraVox001 commented 2 years ago

Another method, easier to achieve, would be this : the size of the connectors (gray balls) must be bigger and bigger when you zoom out the map in the appropriate mode. Thus, the connectors remain very visible, even when the map is zoomed out, which allows to connect switches to very distant lights. Because the only thing that prevents us from connecting them together is the visibility of the gray balls (too small once the map is zoomed out). So, you have to increase their size according to the zoom level.

UltraVox001 commented 2 years ago

Another method is to select the switch, then deploy a list of available lights in the right panel (in the switch panel). All that remains is to select the lights to be connected via checkboxes.

Granada1 commented 2 years ago

Another method is to select the switch, then deploy a list of available lights in the right panel (in the switch panel). All that remains is to select the lights to be connected via checkboxes.

I like that idea

MonkeyFrogStudio commented 2 years ago

The last one (drag from a list of available switches) is the best one you've come up with. I agree.

Personally, I like my Drag from Current Object Area idea (see my first post above). We already have the Current Object Area and it already displays all current objects being used. All they would need to do is implement a way to tell MAX that we want to "connect" an object being dragged from it to one in the viewport. And this could be done via a key combo. For example, holding SHIFT (or whatever key combo) while dragging an item from the Current Object Area and dropping it on an object in the viewport could trigger a warning, asking if you want to connect the two items, something like, "Do you want to make the dragged item a trigger for this item? Click Yes if so. Otherwise click No." Afterward, the two are connected and you could then set up the behaviors. If the key combo is not held while dragging out from the Current Object Area, then it acts as normal and the item is just dragged out of there and simply added to the scene as normal.

UltraVox001 commented 2 years ago

It should not be said that your lights and switches "are not part of the game". This method is used in several 3D engines to handle AI, scripts and arbitrary events. The "Storyboard" is just a name developers give to a sheet. This sheet does not necessarily have to be limited to linking maps to each other, or menus. There may also be other interaction sheets, to handle very different aspects using a similar method (Switches, Lights, Scripts, AI, Doors, Zones, Keypad keys to assign, assign Sounds to ground textures and other InGame objects/elements).

This type of sheet can be enlarged to infinity and zoomed out to infinity (Lee knows this) and give access to all the connections in your game. With ease. This does not mean that you have to stop the development of the visual aspect (with the gray connectors) because it is interesting, but in some cases (very often), another connection method will prove to be very useful.

Personally, if I had to choose a method to connect many very distant objects (and also nearby objects, I admit...), I would choose a "Lightning Panel Connector". In 5 seconds everything is connected. And I didn't need to walk around the map with the editor. It is an essential time saver. This is perhaps what GGMax currently lacks the most : an overall Concept based on something simple, easy and very powerful.

UltraVox001 commented 2 years ago

The last one (drag from a list of available switches) is the best one you've come up with. I agree.

Personally, I like my Drag from Current Object Area idea (see my first post above). [...]

Your method is very good to tie 4 or 5 lights to a switch. When you have hyper massive lighting, with a hundred lights scattered over several floors, and all of that has to be linked to a circuit breaker, you are going to spend time there. A Connector Panel does this in 10 seconds. Left-click and hold to select all the lights to link, then right-click to open a Switch Assignment Menu.

We must try to imagine a concept adaptive to all types of projects. From the simplest to the most complex. Personally I like to work on complex and very complex maps. It's so complex that GGMax is starting to have trouble opening my maps :D

MonkeyFrogStudio commented 2 years ago

Remember, the Current Object Area is also where you can currently display grouped objects, too. So, since you can already have grouped objects, then you can have grouped "lights" and, thus, your idea of all lights of a kind (i.e. all lights that would belong to a single switch could all be grouped and then linked).

UltraVox001 commented 2 years ago

Remember, the Current Object Area is also where you can currently display grouped objects, too. [...]

Yes, I fully understand the method you are thinking of.

It is a method close to the one I propose (the end result is the same), except that it looks different. You prefer to use the left panel because it's already there. I prefer to use a dedicated sheet comparable to the Game Storyboard (a Light Connecting Panel), because the concept is already "integrated" into GGMax. Even if there is still a lot to do!

I am sure that TGC will respond favorably to your proposal because it is useful and easy to integrate. Personally, I aim for overall development over the longer term.

MonkeyFrogStudio commented 2 years ago

This method is used in several 3D engines to handle AI, scripts and arbitrary events. The "Storyboard" is just a name developers give to a sheet. This sheet does not necessarily have to be limited to linking maps to each other, or menus. There may also be other interaction sheets, to handle very different aspects using a similar method (Switches, Lights, Scripts, AI, Doors, Zones, Keypad keys to assign, assign Sounds to ground textures and other InGame objects/elements).

Most game engines I've worked with (Unreal, Unity, S2, etc.) use prefabs or prefab like structures to accomplish this sort of thing. With prefabs you hook-up your switches for doors, for lights, for platforms, etc. and then you can place the individual components as you please, and swap out parts (or add in/out parts) as you please to make each set piece as unique as you want it to be.

As a simple example, with a prefab you can make a simple key and door set where you need a specific key to open a specific door. Then you can use that prefab to swap out key and door models all day long to make unique sets. This way the programming works and the artist can make as many unique sets as the game requires.

Even more complex prefabs can be set up. Perhaps a puzzle needs to be made where the player will need to first find a key that opens a safe. In the safe is a code. The code is used to unlock a box. The box has a button that opens a unlocks a door. This can all be set up beforehand in a prefab using even temp models (even unsightly base-blocks) and the artist can swap them out with finished models later. The key, the safe, the code and box, door, etc. can all be set wherever in the level as pleased by the level designer. And because it's a prefab, it can be used to design several different looking ones, with different keys and different codes, etc., used and reused throughout the game as required.

Prefabs are the way to go, actually. It's easy to set them up. And once you do, you have a base template that can be reused over and over as needed. But prefabs are even more powerful than this. They go way beyond coding things like keys and doors and switches and lights. They make it a breeze to quickly vamp up design work when designing a level.

Here's an example video of someone using Unreal with prefabs for their design work:

https://youtu.be/ieGNMntRV4E?t=374

UltraVox001 commented 2 years ago

Completely agree with you. Rather than selling various 3D objects (but that's good too), TGC should offer us the Prefab system, present in all engines worthy of the name. The first engine I used with Prefabs was Leadwerks Engine. It was a long time ago. Very nice experience. It is a huge time saver and offers unlimited editing possibilities.

PS : I enjoyed S2 Engine very much, but I haven't used it for 3 years.