A blizzard-style "Trigger Editor" would be nice
BeigeAlert
Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
Now I know this would be no small-task to implement, but please hear me out.
I think a blizzard-style trigger editor would go a LOOONNGGG way towards helping modders unfamiliar with lua, as well as hugely expanding the variety of player-made mods. See, in games like Warcraft III and Starcraft II, you don't have to learn a programming language to make a mod. You can do an amazing amount of customization simply with a GUI-based scripting system built into the game.
I'm not proposing to do-away with Lua scripting, but instead to introduce a more in-between option for those who wish to make mods more complex than just using the scripts already provided, but aren't willing/able to jump into Lua, which looks pretty intimidating to someone who has never done any programming before. I'm sure I could pick it up in an afternoon or two, but then again I've got a good chunk of experience under my belt. Ask yourself: what is FP's target audience, and could we reasonably expect say.... 10% of them to be willing to pick up an entirely new programming language on a whim, for fun? Learning a language is a serious time commitment, and I think you're severely restricting your modder-base.
For those unfamiliar, here's a brief description of the Warcraft III trigger system:
-A map's "triggers" are composed of 3 parts: events, conditions, and actions.
-All 3 of the above are created through a sort of mad-libs fill-in-the-blank style gui composed of dropdown boxes and numerical fields. No chance of a syntax error there!
- Eg: "Map Initialization" (no options) or "Time - Periodic Event: Every '2.00' seconds of game time" (numerical entry) or "Unit - Unit Enters Region: A unit enters 'Region'" (a drop-down box containing all the "regions" (rectangular areas specified in the editor) on the map.
-Events make the trigger check conditions. If the conditions are all met, then it moves onto the 'actions'.
- Eg: "Unit Comparison: '(Triggering unit)' 'Equal to' 'Value'" Each of the underlined options is a dropdown box containing options (like "equal to", "not equal to", etc.)
-If those conditions are met, then the actions are performed, one by one, in order... similar to statements in a programming language, but again: everything is composed of user-selected options like from dropdown boxes and numerical inputs -- no actual typing of code (though this IS another option available in Warcraft III too)
- Eg: "Unit - Kill: Kill '(Triggering unit)'
Here's a screenshot to give you an idea what this window actually looks like:
Despite the ease of use, it was actually VERY powerful.
To look at this from a slightly different angle... Warcraft III and Starcraft II have had MILLIONS of players over the years, and there have been a good number of custom maps created for them... some of which were actually not garbage. Future Perfect is NOT going to hit that sort of player base, short of some kind of miracle. Not that I don't think it'll be a great game -- I really hope this game just explodes in popularity -- but I'm trying to be realistic here: low player bases is just the nature of indie games. Therefore, it seems to me that it should be your top priority to make scripting in this game as easy as possible, and at the moment I just can't see 14-year-old me saying "Cool! I completely understand what's going on here".
I think a blizzard-style trigger editor would go a LOOONNGGG way towards helping modders unfamiliar with lua, as well as hugely expanding the variety of player-made mods. See, in games like Warcraft III and Starcraft II, you don't have to learn a programming language to make a mod. You can do an amazing amount of customization simply with a GUI-based scripting system built into the game.
I'm not proposing to do-away with Lua scripting, but instead to introduce a more in-between option for those who wish to make mods more complex than just using the scripts already provided, but aren't willing/able to jump into Lua, which looks pretty intimidating to someone who has never done any programming before. I'm sure I could pick it up in an afternoon or two, but then again I've got a good chunk of experience under my belt. Ask yourself: what is FP's target audience, and could we reasonably expect say.... 10% of them to be willing to pick up an entirely new programming language on a whim, for fun? Learning a language is a serious time commitment, and I think you're severely restricting your modder-base.
For those unfamiliar, here's a brief description of the Warcraft III trigger system:
-A map's "triggers" are composed of 3 parts: events, conditions, and actions.
-All 3 of the above are created through a sort of mad-libs fill-in-the-blank style gui composed of dropdown boxes and numerical fields. No chance of a syntax error there!
- Eg: "Map Initialization" (no options) or "Time - Periodic Event: Every '2.00' seconds of game time" (numerical entry) or "Unit - Unit Enters Region: A unit enters 'Region'" (a drop-down box containing all the "regions" (rectangular areas specified in the editor) on the map.
-Events make the trigger check conditions. If the conditions are all met, then it moves onto the 'actions'.
- Eg: "Unit Comparison: '(Triggering unit)' 'Equal to' 'Value'" Each of the underlined options is a dropdown box containing options (like "equal to", "not equal to", etc.)
-If those conditions are met, then the actions are performed, one by one, in order... similar to statements in a programming language, but again: everything is composed of user-selected options like from dropdown boxes and numerical inputs -- no actual typing of code (though this IS another option available in Warcraft III too)
- Eg: "Unit - Kill: Kill '(Triggering unit)'
Here's a screenshot to give you an idea what this window actually looks like:
Despite the ease of use, it was actually VERY powerful.
To look at this from a slightly different angle... Warcraft III and Starcraft II have had MILLIONS of players over the years, and there have been a good number of custom maps created for them... some of which were actually not garbage. Future Perfect is NOT going to hit that sort of player base, short of some kind of miracle. Not that I don't think it'll be a great game -- I really hope this game just explodes in popularity -- but I'm trying to be realistic here: low player bases is just the nature of indie games. Therefore, it seems to me that it should be your top priority to make scripting in this game as easy as possible, and at the moment I just can't see 14-year-old me saying "Cool! I completely understand what's going on here".
Comments
SC1´s Triggersystem was interesting. Some quick tests, 3 pads on the ground and the very first "pick your Hero"-Minigame was born.
Nowadays the little "pick your Hero"-triggerscript has evolved to some dreaded and feared demon called "Moba".
I know the language, i speak siemens´s7 (wincc-flexible), i can read lua, i can manipulate it to my bidding. I can not write it.
Something about beeing to lazy and having to many other things to do.
Still a huge task to write a visualization for scripts.
It's nothing short of amazing what some people were able to accomplish with Starcraft 1's trigger system. (see: 'Rush episode 1 by Tuxedo Templar' http://sc.nibbits.com/maps/project/69849/rush-episode-1-v10114scx )
It would take a while. I have been working on bits and pieces towards a similar end in a different component based c++ and lua engine. When I have got a better understanding of how the component system works in future perfect, I will be initially spending my time creating lots of different components, so players will be able to easily create custom entities.
Once I have a strong base of components, I will then look at the GUI implementations.
You know me, when I create games, I like to make something where the users create. I was actually planning to write a drag and drop type FPS creator for Spark, but that was going to be too complicated. So I was developing the same idea in a new engine.
Future perfect gives me the opportunity to create this game FPS creator within it, so players can create more complex FPS games, without touching any code. Total Game Creation Inception!!
Of course there will always be a limit to the amount of power given to non-code, eventually programmers will want to learn the code, and they have a great opportunity.
It's probably just reflecting my mentality, but this is the UWE project I am looking forward to the most.
To demonstrate what I mean, I recorded a quick video. This video is intended to give you an idea of what is possible.
Another way to think of this is based on the 3 tiers of creators we envision.
Remixers (Tier 1): Take existing blueprints and worlds from Workshop and reconfigure them. You probably won't see brand new games or blueprints being created by this tier but they will really refine a lot of the games that are created and will be the ones creating a lot of the custom worlds/maps.
Tinkerers (Tier 2): Create new, custom blueprints and Worlds. While these creators may not be creating the actual models, sounds, or scripts, they will be using them in new ways. They may tweak existing assets however. I imagine a lot of the non-game Workshop items (think of objects like helicopters, new weapons, power ups, etc) will be created by this tier.
Makers (Tier 3): Create new assets such as models and scripts. These folks will be creating the basic assets that the above tiers will be using to create their games.
There is no reason a single person couldn't be a member of all 3 tiers and there is nothing that formalizes these tiers. It is just the way we think it will go.
I'm just not a fan of that kind of scripting. It just feels so constricting. There's no control structures whatsoever ( if, loop, etc. ), and you can't as easily say "do x... WAIT 2.00 seconds... then do y if a, otherwise do z". Yea it's simple enough and easy to understand... but it's not very flexible at all (again, the idea here is to NOT be dependent on lua for all your flexibility), because with that comes a lot of unnecessary syntax that I'm convinced is going to turn people off doing much of anything with this game. With the way they had it in Warcraft 3, it was super simple, but also super flexible. You could make your triggers as simple or as complicated as you wanted... it just sort of scaled up with your depth of understanding.
The component system is probably good enough for just simple stuff like little pieces of a bigger whole game, but let's think bigger here! What if you wanted to make some kind of a boss battle or something? That's a bit more complex than you'd be able to cram into a few pre-built scripts. With the system I'm proposing, you wouldn't need to touch Lua at all!
Also, I think you guys are vastly overestimating your average gamer's patience and programming competency. Even with the simplified trigger system that was present in Starcraft and Warcraft III, I would still fairly regularly hear people comment about "oh I just don't understand that triggers stuff." (aka the easy stuff). Can you imagine if Blizzard had just stuck with a scripting system for Warcraft III? I'll be so bold as to say we wouldn't have seen even a TENTH of the custom content in that game that we got thanks to a simple, flexible system of scripting. And again, this is a Blizzard game we're talking about: MILLIONS of people played this game. Of those millions, maybe 10% played custom maps. I was fairly active on Bnet back in the day, and I would estimate that for every 100 players playing custom maps, only 1 of them was actually a map maker who stuck around long enough to make something cool. That doesn't extrapolate well for a much smaller player-base.
Look at ns2. How many custom maps actually are getting finished? I can probably count on both hands that number... 1 hand if I only talk about the good ones. So you guys saw this and came to the conclusion that the editor was a bit too complicated, and for Spark 2.0, the editor is MUCH more user-friendly. That's awesome!
I just don't want this game to suffer because only a small handful of people bother making content for it because the others are intimidated by the scripting.
How about something like a "Trigger Actions" component that takes scripts as its editable variables (a re-orderable list in the editor, turns into an array?)
The problem then is how we input the variables into the action scripts.
I think the separation of actions and triggers and some type of flow control would solve most of this.
Without this, scripts will have to be much more specific and less modular.
The whole point of a component system, is that every component is responsible for just one task. This way every component is very, very, specific, but that makes it much more modular, not less modular.
For example. A basic player may have health, score, inventory, etc, but these would all be individual components.
Health component would be responsible for health, the adding, removing and resetting of, but nothing else.
Score component is responsible for the score, adding, changing and resetting, but nothing else.
This is very specific, but it allows greater freedom and modification. With a component system, I would say that ultimately, it should be easier to create the scripting system in FP, than it was in WC3, but getting it to that level of completion would take a huge amount of time and effort.
As I understand, the things you currently see are just an example of what you can do with the system. Of course, they will need to add functionality like interactions between multiple components e.g. activate 2 buttons to open a door. I think they can manage to realise that in their editor without the need of abstracting it into a seperate GUI with another script language layer in between. LUA is in no way more diffucult to learn than the abovementioned JASS, if people get interested in modding this game they will learn it. The rest can use the premade components and scripts in the editor which is a lot more intutive than the wc3/sc editor.
@Soul_Rider No, the point of a component system is to have components - objects that you can configure. A player is a component, his health, score, inventory are either attributes or other components that get assigned to the player component. That's the beauty of it, it kind of simulates the real world.
Say I have want to trigger opening and closing a door.
The door blueprint has a script with Open and Close methods that can be called with World_QueueMessage.
Today, we do this:
To open and close the door, we can make an OnTrigger script that calls those methods on enter and exit (call it "Control Door on Trigger). We add this script to any object with a trigger, then link up the door to the script.
But what if we want to add a delay - when we exit the trigger, the door stays open for 10 seconds, then it closes.
We then have to add a delay to one of the scripts - probably the trigger.
Now we have to include a delay variable and logic to the "Control Door on Trigger" script, or we have to make another script "Delayed Door Control On Trigger".
Now, what if we want to add a warning light before the door closes, that turns off once the door is closed - on trigger we want to turn on the light, then after 10 seconds close the door, then after another 2 seconds turn off the light.
Now we can either try to add delays/timers to all of the scripts, trying to match up the delays by hand. Or we make a custom on-trigger script that controls everything.
Either we bloat all the scripts by adding delays, or we make a very specific OnTrigger script that isn't reusable.
I have never said anything against the component system, I think it's great. I just think we could use a more robust event/trigger/action system rather than one single event for everything to trigger on at the same time.
Very few used JASS, most stuck with the GUI triggers.
Maybe I've just misunderstood the whole angle that FP is going for, but I was under the impression that it was supposed to allow the layperson to make new game modes or modifications to existing game modes. Learning a programming language is NOT for the layperson. Yea it's easy for us, but all of us in this thread have done a fair bit of programming before. Picking up a new language is trivial. But what about for your average gamer type? Are we limiting FP's audience to just those who have a programming background?
I dont see why FP shouldnt be able to do that #-o
I'm just trying to make a case for why this should be added, which would surely eat up a ton of development time. I think it would be worth it though.
Let me explain components more clearly.
First off, you have base components, like score, health, inventory etc as posted in my example earlier. On their own, they are just empty components, but I use these components to create the entities I require.
So I would create a base player component and a relevant script. This would be made up of the individual components, and the new base player script controls the talking to each of the components.
So in your door example, models, physics, etc would all be components, and they would be combined in a script called 'door' which then worries about timing and states.
This is more flexible than having an over-arching heirarchy, that forces variables and methods on sub-classes that don't need it.
I think that I understand how entities and components work.
There is no player script, there is an avatar blueprint that consists of an entity with multiple individual scripts - there is no unifying base script, it's all individual components that talk to each other.
I don't understand what point you're trying to make, I have never made any case for any over-arching hierarchy.
The current way of doing using OnTrigger scripts lacks a decent way to order, delay or contol effects.
Currently, the way to use a trigger is by: add the trigger component to an entity, then add a script to the entity that has an OnTrigger function. This way all scripts with an OnTrigger get executed at once when we enter the trigger's box.
You solution is to make more scripts?
Once again - I'm not proposing an external editor for anything, all I'm proposing is a way to execute actions sequentially, instead of all at once.
What I'm trying to say with my example is that the current way of doing things in FP doesn't have an easy way to modularly/sequentially use actions.
I think it would be better to, instead of having a bunch of "Do X on Trigger" scripts, having "Do X" scripts that can then be invoked in different ways(for example on a trigger), without modders having to write their own code.
Are you saying in my door example, that we should bloat our blueprints and add all possible use cases scripts? Or that we simply force all modders to write their own scripts?
EDIT: I'm tinkering with some scripts and I'm not sure how my approach would work when it comes to targets of stuff. If I have an action for "add score" that can be called by a trigger or a use-script for example, how does it know who to add the score to? How would the event data be piped to the action?
I might actually just mod the "Activate On Trigger" to make a delayed "Send Message On Trigger" that can send any message on trigger, or maybe I'll just stick with "Activate" messages.
Every map that had custom made spells use JASS, it was needed to make the awesome spells of DotA, Warlock, Castle Fight, Enfo's, Spellcraft - i could continue.
Yea but those are not "most" maps. That's a partial list of many of the most complex maps. Remember, I'm talking about making the scripting more accessible to the layman. Layman isn't going that advanced.
@bERt0r A component is a container for variables or sets of methods to perform a task. Components can be combined and added to entities, or other components, to create unique entities. Components are the basic building blocks.