Jump to content

Recommended Posts

Posted

First, let me applaud everyone who is working in this area. I think it's a great thing.

 

I'd also like to share some thoughts with you of what these editors could be, if a great deal more effort is invested in their development.

 

When Jeff first started releasing snippets of what BoA was to be, I suggested he needed some good dialog tools that would translate some of the more common tasks (door settings, etc.) into script. He agreed this was a good idea, but it didn't happen.

 

If we want to include a larger developer base in BoA, we need tools that make it easy to develop scenarios.

 

Tools that I'm seeing now are a small step in that direction, but they still require one to understand the underlying scripting paradigm they are based upon.

 

What would be great is a tool that used a different paradigm for the interface, then translated the user's input into scripting.

 

For example, imagine a dialog generator that used a graphical interface, where boxs of text could be inserted and then arrows could tie dialog chunks together. The boxes could be dragged about on the screen and rearranged to visually represent flow.

 

With this tool, you are free to concentrate on the dialog interactions themselves. The code is then generated for you. Just as in Windows or a Mac, dragging an icon is translated into code behind the scenes.

 

There are many benefits to this approach, but the main one here are a larger developer base. That translates to more scenarios, more growth, etc.

 

Now I'm sure some will argure that not all aspects of BoA scripting could be covered by this approach, and you are right. If we make as many things as simple as possible, well, that's a good goal to shoot for.

 

Just some thoughts. IMO, BoE succeeded because it was dialog based - even if those dialogs were primitive.

Posted

BoA has too much orthogonality for this to really be effective. After AvDialogue is done I'm going to toy with the idea of creating a node-based system, but no guarantees.

 

Oh, and BTW--you wouldn't be able to "drag around" parts of a dialog box. For the most part, they're fixed in place by code.

 

EDIT: My CallWizards idea does what you're talking about, but you have to know how to script. And frankly, I don't want people who can't script making scenarios. If you don't know what you're doing, it's counterproductive to put out slop.

Posted

With an editor though it should be able to work like that. The interface would change the code that fixes the dialogue in place. I suppose that would be rather complicated but it is just an example....

 

Hmmm would you restrict it to just 100 nodes? or maybe 1000, or much bigger?

Posted
Quote:
Originally written by m's avatar:
With an editor though it should be able to work like that. The interface would change the code that fixes the dialogue in place. I suppose that would be rather complicated but it is just an example....

Hmmm would you restrict it to just 100 nodes? or maybe 1000, or much bigger?
Unlimited nodes, but I'm still limited to 10-99 as states.
Posted

Arenax, you missed Brett's point rather badly. The idea is that one could create a visually-oriented program that would then write script. The "state =" and "nextstate =" could be represented by lines connecting dialogue text.

 

People who don't know how to script aren't necessarily identical to people who don't know how to write stories and develop interesting scenarios. The idea is that the process of scripting could be made easier, not that people would create scenarios without scripting.

Posted
Quote:
Originally written by Kelandon:
Arenax, you missed Brett's point rather badly. The idea is that one could create a visually-oriented program that would then write script. The "state =" and "nextstate =" could be represented by lines connecting dialogue text.
I caught it, Kel (though I was half-asleep and the "dialog box" part sort of confused me). I was explaining from a technical standpoint why that wouldn't work for most scripts. Dialogue scripts, yes--but even those, not to the extent he's talking about, simply because of the way they're structured. You'd have to restructure them in your own code in order to deal with it, which is possible but unlikely.

For instance, try to come up with a way to "visualize" a town script. The only way I can see to do it is with nodes, and that wouldn't work for a host of reasons, most of them dealing with the fact that Avernumscript is not always a linear language.

Quote:

People who don't know how to script aren't necessarily identical to people who don't know how to write stories and develop interesting scenarios. The idea is that the process of scripting could be made easier, not that people would create scenarios without scripting.
Anything that removes control from the user will cause problems, especially if the user is not conversant in the ways to solve the problems. Avernumscript is excellent BECAUSE you have control, and abstracting that control will do little but cause problems.

EDIT: I can't remember who to credit this saying to, but IIRC, it went something like this:

The more simplified something is, the less useful it can be.
Posted

That quote presumes you're working with a system that is of sufficient complexity that simplicity would limit its abilities.

 

The dialogue system for BoA is no such thing. It's like saying the invention of the typewriter limited the usefulness of words.

Posted
Quote:
Originally written by Morgan:
That statement presumes you're working with a system that is of sufficient complexity that simplicity would limit its abilities.

The dialogue system for BoA is no such thing. Its like saying the invention of the typewriter limited the usefulness of words.
To be frank, if you can't do dialogue by hand, it's unlikely that you grasp the most basic principles of Avernumscript. I made AvDialogue to eliminate the tedium, not to remove the functionality.
Posted

Let me put it another way: we're not seeking to simplify the system, but rather to represent it in a different way.

 

One could represent the "state =" and "nextstate =" as line connecting text boxes. Those text boxes could be the "text1 =" and "text2 =" and so on. I suppose one could have a "personality =" box above the text boxes.

 

I suppose one could then put an "action =" menu right below the boxes with all of the possible action calls as menu choices. Then underneath that, one could put a "code =" box that could be filled in with optional code. Oh, and above those two, a "condition =" box, which, if not set to 1, would change the color of the connecting lines.

 

After all of this was filled in, one could press a button that says, "Generate script," and it would create a text file with the appropriate code.

 

With enough features (being able to import an already-made script, not creating a code line if nothing was in it so that if the "condition =" box had nothing in it then no condition line would show up in that node, etc), this program could replace scripting dialogue by hand.

 

There's no point in arguing about it, really. I don't have the technical skill to make such a program, so obviously I'm not going to. If Arenax doesn't want to, then he's not going to, either. Someone else may or may not.

Posted

If someone provides a document detailed down to the most minute level, I'll take a crack at it.

 

But it's an idea that strikes me as wholly unnecessary and the creation of a floodgate for "kewl i can make a scenario w00t" types. Maybe I'm wrong--but that's what BoE had for a long time.

 

EDIT: And you're still seeking to simplify it. :-P

Posted
Quote:
Originally written by Arenquacks:
The more simplified something is, the less useful it can be.
Victorinox_52003_WEB_small.jpg
lever.jpg

Other examples: alphabetic writing vs. ideographic, the wheel.

Complex systems are simply what arises out of the interactions of simple components. Even your computer is, at its base, a series of aggregations of simple components. All of your software is composed out of a rather simple, limited set of hardware instructions.

Complexity does not render utility; flexibility does. It is a fatal error (albeit common to programmers) to conflate the two.
Posted
Quote:
Originally written by Drakefyre:
IMO, what would be the best would be something exactly like the BoE dialogue editor but for BoA.
This is something I feel safe in calling impossible. The two operate on entirely different principles. BoE's dialogue editor was kludge and relied upon a system incompatible with BoA's.

Quote:

And a lot of people would probably use a monster/item/terrain editor like BoE's too.
...Oh teh nos, something slightly complex that can be done with but a very simply program! o.O

Sorry if I sound sarcastic, but the current system works well and is considerably more powerful than BoE's. Dumbing it down is a bad idea.

Oh, and Walker: Computers are not levers. Complexity in a programming language or scripting language almost always confers flexibility. The removal of a language's complexity almost always reduces utility. I can come up with examples to prove the opposite and I'm sure you can too--but they're few and far between.
Posted

Representing a system in a different way is not dumbing it down. I myself understand dialogue pretty well, but it would be easier if it were represented visually. For two years in high school physics, my teacher forced us to draw diagrams for every physics problem that we got. Was that dumbing down the problem?

 

It's not removing complexity. All of the components are still there. It's a matter of changing the representation. Simplifying something only becomes a problem when you lose utility, and the program that I'm imagining would not erase any components.

 

Programs have been made that do individual parts of a custom objects script already, but they aren't very good, not because they dumb down the system — they're actually easier to use than writing raw code — but because they don't have enough features. They can't handle more than one object at a time, and they can each only do one type of object, for instance.

 

Arenax, I recommend you look at the description that I posted above and tell me exactly what would be missing from such a program. What could one do writing raw code that one could not do with the program that I described above?

 

Similarly, take a look at an editor for custom objects scripts that has already been made and tell me what one could do writing raw code that one could not do with such a program. This creature editor and its cousins need more features, certainly, but I challenge you to tell me how they are less powerful than scripting directly.

Posted
Quote:
Originally written by Kelandon:
Representing a system in a different way is not dumbing it down. I myself understand dialogue pretty well, but it would be easier if it were represented visually. For two years in high school physics, my teacher forced us to draw diagrams for every physics problem that we got. Was that dumbing down the problem?
Don't get me started on physics and diagrams.

Quote:

It's not removing complexity. All of the components are still there. It's a matter of changing the representation. Simplifying something only becomes a problem when you lose utility, and the program that I'm imagining would not erase any components.
Now we come to something of a slippery-slope argument. On its own, this design is acceptable (but not one I'd personally use, as I dislike the entire idea of visualizing it because I don't find it necessary). But once you simplify dialogue--what must now be done is simplify script editing, which is where the real problem lies.

The only real issue with your design is that coding it would be awfully difficult and probably out of my league if I wanted it to be cross-platform. I'm not saying it's not possible for others--but the benefits are outweighed by the inherent issues. I wrote AvDialogue because I needed something to speed up writing dialogue, not to idiot-proof it for me or make it more "understandable," because as it stands Avernumscript is perfectly understandable.

Quote:

Programs have been made that do individual parts of a custom objects script already, but they aren't very good, not because they dumb down the system — they're actually easier to use than writing raw code — but because they don't have enough features. They can't handle more than one object at a time, and they can each only do one type of object, for instance.
Gimme a week after I release AvDialogue2, okay? I'll fix that little problem. (And once I do that, kick me so I remember.)

Quote:

Arenax, I recommend you look at the description that I posted above and tell me exactly what would be missing from such a program. What could one do writing raw code that one could not do with the program that I described above?
Nothing. However, the GUI-based complexity of such a design makes it very prohibitive.

Quote:

Similarly, take a look at an editor for custom objects scripts that has already been made and tell me what one could do writing raw code that one could not do with such a program. This creature editor and its cousins need more features, certainly, but I challenge you to tell me how they are less powerful than scripting directly.[/QB]
I can't, because I can't get to the website. :p

Besides, this sort of thing is not actual scripting so much as it is data entry. These don't bother me nearly so much as the people who want a BoE-style node editor (which I've explained as somewhere between unlikely and impossible).

I make programs that I would use, and the visualization stuff isn't something I'd use, so I probably wouldn't make it. That's just how I am.
Posted
Quote:
Originally written by Arenax:
Now we come to something of a slippery-slope argument. On its own, this design is acceptable (but not one I'd personally use, as I dislike the entire idea of visualizing it because I don't find it necessary). But once you simplify dialogue--what must now be done is simplify script editing, which is where the real problem lies. Again, you're taking this to a different place than I am. I agree with Brett, who said, "Now I'm sure some will argure that not all aspects of BoA scripting could be covered by this approach, and you are right. If we make as many things as simple as possible, well, that's a good goal to shoot for." Let's make dialogue and custom objects script editors now, because making good editors for those scripts is far easier than for town scripts and no such editors exist, and we can worry about town script editors later. They may not use the same ideas at all.

However, if a town script editor included all of the same capabilities as writing raw script — and I'm not sure I would make the distinction that you make between "data entry" and "real scripting," because what I'm suggesting may be "data entry" — then I couldn't argue with it. The goal is not to dumb this down so that we have BoE all over again; the goal is to make the system more user-friendly so that people who can write good stories won't have to worry about learning how to program in order to make scenarios.

BoA has the inherent problem that the people who are capable of writing good stories and therefore plots that we would want to role-play are usually not the same people as the ones who can code very well. To put it another way, math/science/computer people are usually different from humanities people. But ultimately we would like to attract writers as well as technical innovators, because the writers are the ones who will make good scenarios.

Any editor aid that will make it easier for humanities people to write a scenario — and has the same abilities as writing raw script — seems like a good thing.

The only real issue with your design is that coding it would be awfully difficult and probably out of my league if I wanted it to be cross-platform. I'm not saying it's not possible for others--but the benefits are outweighed by the inherent issues. Inherent issues? It seems like you're saying that my idea is bad because it would be hard for you personally to program. I'm not asking you to program it, and you are not the only programmer out there. I'm going to learn C and C++ one of these days — over Winter Break I'll start, probably — and I may make this program myself.

To be more explicit: I'm not really talking in your direction, Arenax. Not everything is about you.

I wrote AvDialogue because I needed something to speed up writing dialogue, not to idiot-proof it for me or make it more "understandable," because as it stands Avernumscript is perfectly understandable. That's great. However, you know multiple programming languages. Other people don't. One shouldn't have to learn C in order to make a scenario, at least in my opinion. We want people who can write good stories.

Also, certain people around here think that it's important to work for the community and not just for one's self. My favorite thread on any message board ever has entire paragraphs relating to this. To quote Alcritas:

"I believe it is the responsibility of every member of any community, including the BOE community, to contribute to the community's strength and well being.... I find the view that individuals do not bear any ethical or moral responsibilty to contribute to a community they receive benefits from nothing short of pathetic."

One can replace everything he says about "fun" with "useful to me" and the same argument would apply (probably better) to this situation.
Besides, I don't really understand what the problem is with the "kewl i can make a scenario w00t" mentality. BoE has almost 250 scenarios. Roughly a third of those are garbage that no one would want to play anymore.

However, you of all people should understand this, Arenax, because you were around for the early years of BoE: activity in a community is good. A bad scenario released is better than no scenario at all. Where would BoE be if the only scenarios released during the first year were Tatterdemalion, Nephil's Gambit, Requelle's Nightmare, RotS and DotS, and Islands of the Wheel? BoE had dozens of scenarios released over the first year, and it was better for that flurry of activity, even though for every Nephil's Gambit there was a Compositus.

I think that the day when Micael releases Undead Valley will be a good day for the community, because it's a new scenario. Never mind that it's bad; it's still a scenario that people can play. We have people who like fighting in the arena in the HLPM, for crying out loud. We as designers should give the players what they want, and the overwhelming consensus is they want new scenarios, regardless of quality.

Wow, this turned into a long rant. I'll be coming back to these points repeatedly over the next few months, probably.
Posted

Let me try and evaluate your position here, Arenax. You're being so unbelievably elitist that you can't even begin to comprehend that there are different disciplines involved in designing a scenario, of which the actual programming is probably the least important.

 

And yet you maintain such an enormous ego that obviously believes that if somebody wants something that makes their job a little easier it must therefore follow that they are guilty of "dumbing down".

 

Like Kelandon said, I fail to see the problem with newbies creating scenarios. The very notion that you woulod hold such an idea as being undesirably is indicative of your incomprehensible elitism.

Case in point - TM came to this community with Streila Spies, a pretty horrible scenario, yet his latest effort for BoE, NTH, is considered to be one of BoE's finest.

 

Ok, so for every person like TM you have a lost_king or Vince Fizz. But I'd rather make things easier for newbies in the hope of one shining designer to break the mould than shut the doors completely to new blood, leaving a community to completely stagnate.

Posted
Quote:
Originally written by Morgan:
Let me try and evaluate your position here, Arenax. You're being so unbelievably elitist that you can't even begin to comprehend that there are different disciplines involved in designing a scenario, of which the actual programming is probably the least important.
Show me a well-written scenario in which the writer was not a capable programmer. I seriously doubt that you can, with perhaps one or two exceptions.

Quote:
[qb]
And yet you maintain such an enormous ego that obviously believes that if somebody wants something that makes their job a little easier it must therefore follow that they are guilty of "dumbing down".
Tell me--who's making the tools to make things easier for people? Seems like I'm the main one on the Windows side right now, and I'm working on going multiplatform.

What I am against are tools that abstract things to too great a degree. Dialogue editors are fine; my only problem with Kelandon's suggestion is one of programming complexity, not usefulness (well, that and my personal aesthetics, which don't involve that sort of thing).

Quote:

Like Kelandon said, I fail to see the problem with newbies creating scenarios. The very notion that you woulod hold such an idea as being undesirably is indicative of your incomprehensible elitism.
I played BoE a long time ago, and very nearly stopped playing shortly afterwards, primarily because of lousy scenarios. I beat Nephil's Gambit, Tatterdemalion, and the others good ones; what more was there to do besides make my own scenarios (which I did)? Not much, considering the pure agony most of the early scenarios were.

I have nothing against newbies making scenarios--but I've been around long enough not to have a problem with it. Others may.

Quote:

Case in point - TM came to this community with Streila Spies, a pretty horrible scenario, yet his latest effort for BoE, NTH, is considered to be one of BoE's finest.
Wouldn't know, I don't have BoE anymore. However, from what I've seen, I agree with you so far.

Quote:

Ok, so for every person like TM you have a lost_king or Vince Fizz.
Or four of them.

Quote:

But I'd rather make things easier for newbies in the hope of one shining designer to break the mould than shut the doors completely to new blood, leaving a community to completely stagnate.
As would I--but creating dumbed-down tools isn't the answer. More effective methods of teaching how to use the software--better tutorials, etc--are.

Editors to remove tedium? Sure. That's what AvDialogue2 is for. But editors that simply do things for a user who doesn't understand the principles behind them? No.
Posted
Quote:
Show me a well-written scenario in which the writer was not a capable programmer. I seriously doubt that you can, with perhaps one or two exceptions.
And of course, you missed my point entirely. I'm not saying that you can do without programming. But I think we should be aiming for allowing people who are good writers but not necessarily excellent programmers to create scenarios as well as those who do both.

Quote:
Tell me--who's making the tools to make things easier for people? Seems like I'm the main one on the Windows side right now, and I'm working on going multiplatform.

What I am against are tools that abstract things to too great a degree. Dialogue editors are fine; my only problem with Kelandon's suggestion is one of programming complexity, not usefulness (well, that and my personal aesthetics, which don't involve that sort of thing).
The whole point of BoA full stop is to simplify programming for the less able. Are you actually suggesting that because BoA is simpler to use than say, C++, it has no right to exist? If we're using that logic, then we are already far, far down the supposed slippery slope.

Quote:
I played BoE a long time ago, and very nearly stopped playing shortly afterwards, primarily because of lousy scenarios.
What you are describing is exactly the same for every artistic medium you care to mention. But was the invention of the printing press a good or a bad thing for literature? Sure, you had a lot more crap seeping through, but you also had a lot more good.

Quote:
Editors to remove tedium? Sure. That's what AvDialogue2 is for. But editors that simply do things for a user who doesn't understand the principles behind them? No.
I don't even begin to understand the principles behind BoA, does that mean that I'm not qualified to make a scenario? Again with the elitism.
Posted

What I don't understand, Arenax, is against whom or what you're arguing. No one wants dumbed-down tools. The question is how to create tools that have the same power as handling raw script and are easier to handle.

 

I don't know how you manage to start bickering on every thread that you enter. I think Imban's characterization fits well: "You clearly do not play well with others."

 

EDIT: For instance, you may notice that no one on this thread has suggested a node-based town script editor. Why you would discuss a town script editor when you haven't finished porting your dialogue script editor or even made your custom objects script editor yet, I don't know.

 

One thing at a time, dude!

Posted
Quote:
Originally written by Morgan:
Quote:
Show me a well-written scenario in which the writer was not a capable programmer. I seriously doubt that you can, with perhaps one or two exceptions.
And of course, you missed my point entirely. I'm not saying that you can do without programming. But I think we should be aiming for allowing people who are good writers but not necessarily excellent programmers to create scenarios as well as those who do both.
Certainly. Why else would I have conceived of the CallWizard idea for AvScript? Morgan, I never once said that a degree of simplification isn't good. But too great of an extent results in a nice wide stream of crap.

Code assistants make sense--they reduce time and also provide a reference for people looking to improve upon their knowledge. Something that codes FOR you, which is the primary thing I'm against (a node-editor script system, which has been mentioned previously), doesn't teach you.

Quote:

Quote:
Tell me--who's making the tools to make things easier for people? Seems like I'm the main one on the Windows side right now, and I'm working on going multiplatform.

What I am against are tools that abstract things to too great a degree. Dialogue editors are fine; my only problem with Kelandon's suggestion is one of programming complexity, not usefulness (well, that and my personal aesthetics, which don't involve that sort of thing).
The whole point of BoA full stop is to simplify programming for the less able. Are you actually suggesting that because BoA is simpler to use than say, C++, it has no right to exist? If we're using that logic, then we are already far, far down the supposed slippery slope.
Avernumscript is a scripting language. C++ is a programming language. It only makes sense that there is a level of simplification. In this case, it makes it manageable. In the concept that you folks seem to be arguing for, it makes it unmanageable.

Quote:

Quote:
I played BoE a long time ago, and very nearly stopped playing shortly afterwards, primarily because of lousy scenarios.
What you are describing is exactly the same for every artistic medium you care to mention. But was the invention of the printing press a good or a bad thing for literature? Sure, you had a lot more crap seeping through, but you also had a lot more good.
We've gone over this before. "Good" work comes from people who are both good writers/designers and good programmers. If the writing, designing, or programming are lacking, so is the scenario. A program can't make your scenario for you, no matter how much you might wish it could.

Quote:
Quote:
Editors to remove tedium? Sure. That's what AvDialogue2 is for. But editors that simply do things for a user who doesn't understand the principles behind them? No.
I don't even begin to understand the principles behind BoA, does that mean that I'm not qualified to make a scenario? Again with the elitism.
Frankly, yes, it does. If you cannot understand the scripting system, I don't see how you can grasp what possibilities it provides--and so the likelihood of you making any sort of scenario that's more than just playable is remote at best.
Posted

You want me to show you an amazing scenario written by someone who can't program? Pick your favorite commercial game. [All games in a series are included]:

· Baldur's Gate

· Neverwinter Nights

· Ultima

· Kings Quest

· Diablo

And that's just RPG's. All of them were written, designed, and produced by and large by people who had very little knowledge of programming. The coders were essentially just drones. In the broader world, why should you be able to eat if you can't grow your own grains, fruits, and vegies, and raise your own cows. Can you do all of the number crunching required to figure out how to display your commands? Heck, can you convery your programming commands into ons and offs? If your premise is "we should not have mechanisms to simplify coding into a more accessable interface," aren't you a bit of a hypocrite in using Blades of Avernum's editor instead of making your own game, or even using a computer instead of creating your own custom single-game console?

Posted

The Leaving is a good scenario that has very little technical complexity.

 

Also, I thought Malkriss was pretty good, despite being quite simplistic and buggy.

 

Brett Bixler has a decent grasp of BoE's nodes, but that's more through determination than natural aptitude. Most of his stuff is pretty simple. More exotic sequences, like the animation in Quintessence, end up a bit clumsy.

 

All of these would be improved by a visual-based system to help make scripting easier.

Posted

Good coding helps, but it is not everything. Question- would you rather have a decent, unremarkable scenario made by a non-programmer, or no scenario by a non-programmer?

 

But even more than that, since I myself am being thrown around as an example here, people don't start off at the top- but that doesn't mean they have to stay on the bottom. Capitalism is not a meritocracy, but programming for BoA in many ways is. Maybe hard work isn't the whole pie, but if a designer wants to design, don't hold something against a tool.

 

For instance, when learning calculus, one can assume that a limit exists and determine the methods to reach it. Some people need to see it- I sure did. Without graphing calculators, there would be less than half of the people in the classroom who would grasp calculus as quickly as the others, but those other people now know how to do calculus (or at least that aspect of it- god knows I'm floundering with other portions) just as well as everyone else.

 

Similarly, if you make a took that lets people see how it's done, they will be able to make scenarios now, and they will be able to do so in the future without the tool. How did I learn BoE? Same way I learned BoA (except with not as much time taken up in-between): I fumbled, I experimented, but even moreso, I looked at scenarios in the editor and figured out how they did that which they did. How did one-times work? I checked. How did special encounters work? I checked. If I had an intuitive manual or a device, though, I wouldn't have required half of the time and could have done it much quicker than I would have been able to otherwise.

 

God. I can't believe you're really arguing that you shouldn't be making a tool.

Posted

For me, I would really like to design with BoA, and earn some respect out there, and most importantly, to make a good scenario. I am having some problems getting my copy of BoA, but it will (hopefully) come soon. I kind of got the BoE-node thing down, but I have not had the time to throw a scenario out there... maybe sometime in the future. I really want to design for BoA when it is still new and fresh. I am not really programming-savvy, so I have a feeling I will have a hard time with this scripting thing. Newbs like me will need some help to make scenarios, and like TM said, how can you debate NOT making a tool?

Posted

In the absence of tools, use text editors. Look at the BoA editor to identify a place where something happened, and then look it up with a text editor. Then read the manual (the appendices are worth more than the normal docs) to understand the calls. Then do it some more.

 

Eventually, you'll be knowledgeable enough to make a fearsome goblin dungeon. And you can build up from there.

Posted

Well, I have learned C++ and Visual Basic, I haven't caught got the hang of C++ yet but still more experience then the average person.

 

Yet I would still prefer a visual tool for creating BoA script. I suppose I could teach myself, but who really wants to spend all their time learning with what is essentially supposed to be a game?

Posted

The things that I suggested are not dumbing down in any way - they're just putting a GUI onto the coding. I don't see what's so bad about that - I could whip something like that up in Java in about an hour and wouldn't lose any functionality.

 

Just because you can't do it without sacrificing functionality, it doesn't mean that someone else can't.

 

The GUI is what people want more than anything - they want a face on the code. There doesn't have to be anything lost by including it, and I don't see why think that there is any compromise of scripting power.

Posted

Wow - I never expected this to go on this long!

 

I simply feel there are people out there with minimal programming skills that have great stories to tell.

 

BoA's current scripting system will never allow them to express those stories.

 

Tools that translate a visual metaphor into script would help them.

 

What we have now only allows a small subset of the population to create a scenario.

 

I'm not critizing anyone for not developing these tools - it would require a tremendous effort to do so.

 

The Creator is right about me - I'm not the best coder in the world, but I am stubborn. It took me three attempts to get the Missionary and Cannibals code in Quintessence working correctly. Not many people are as stubborn as I am.

 

Because of that, I'll add one very controversial statement: BoA will never achieve the level of success BoE enjoys, because it's too hard to script. Time will prove me right or wrong.

Posted
Quote:
Originally written by Drakefyre:
The things that I suggested are not dumbing down in any way - they're just putting a GUI onto the coding. I don't see what's so bad about that - I could whip something like that up in Java in about an hour and wouldn't lose any functionality.

Just because you can't do it without sacrificing functionality, it doesn't mean that someone else can't.

The GUI is what people want more than anything - they want a face on the code. There doesn't have to be anything lost by including it, and I don't see why think that there is any compromise of scripting power.
A BoE-style dialogue question in an hour? (That begs the question, why bother?)

I was not specific enough in what I said. The BoE dialogue editor idea wouldn't work; the other would work fine and it's something I've already done (I'm just hammering out bugs before releasing that, too).
Posted

Heh. If people are so determined to make things less easy for them, they shouldn't use a text editor. Instead, get a very small magnet and move it in patterns over a floppy disk.

 

Then again, it's not like I'm not against things like .NET.

Posted
Quote:
Originally written by Silence in Motion:
Wow - I never expected this to go on this long!

I simply feel there are people out there with minimal programming skills that have great stories to tell.
So...they can develop programming skills? Sorry, Brett, but here I disagree fully. Programming is not that hard a concept to grasp, and Avernumscript is a very simple scripting system. I would have preferred a Python derivative, but this is still a very, very easy script language.

If a non-programming friend of mine (and not a computer/math geek at all) can sit down in front of BoA, with its documentation, and pick up a working knowledge of Avernumscript--enough to write workable town scripts and such, I'm not saying he could do a creature script off the bat--in a couple of hours, I can't say that I believe it's that hard.

Quote:

BoA's current scripting system will never allow them to express those stories.
Not if they don't want to put in the effort, no.

I for one am not a natural programmer; I don't think that way. I have to put in a fairly large amount of effort to work at it--but I recognize the value of flexibility and utility over glossing over the important parts of a language.

Quote:

Tools that translate a visual metaphor into script would help them.
Hiding the scripting language so they don't learn it doesn't help; it exacerbates the problem.

If you do not understand the language, you don't know what it can and cannot do.

Quote:

What we have now only allows a small subset of the population to create a scenario.
The subset who want to put effort in and actually work at making a scenario, sure.

Quote:

I'm not critizing anyone for not developing these tools - it would require a tremendous effort to do so.
Less than you'd think--I've already more or less completed what you outlined for a dialogue editor, minus the pwetty pictures. A custom item editor will be forthcoming, too.

I have one problem with these tool ideas, however, and it's a very simple one. Simplified tools lose functionality. If functionality is lost, then they aren't worth a damn.

Quote:

The Creator is right about me - I'm not the best coder in the world, but I am stubborn. It took me three attempts to get the Missionary and Cannibals code in Quintessence working correctly. Not many people are as stubborn as I am.
And your determination shows through in your scenarios (I haven't played Quintessence--no BoE anymore--but I played your older ones). You may not have an intuitive grasp of it, but you're willing to work at it, and it makes for a better outcome.

Quote:

Because of that, I'll add one very controversial statement: BoA will never achieve the level of success BoE enjoys, because it's too hard to script. Time will prove me right or wrong.
I agree. BoA's scripting takes a modicum of effort--hell, making towns and dungeons alone does now, even without the addition of scripting.

BoE's is simple but very limited and requires ridiculous workarounds. BoA's is slightly more difficult (and I'm not understating it when I say "slightly"--I apologize if I sound arrogant, but it's really very easy in comparison to most scripting languages), but far more powerful.

So people who want the utility of a useful program will go to BoA. People who want to make scenarios quickly and not worry about what they're missing will stick with BoE. I'm not saying that's wrong; I am saying that trying to make BoA like BoE isn't going to work.
Posted
Quote:
Originally written by Lemon-Flavoured Oracle:
Heh. If people are so determined to make things less easy for them, they shouldn't use a text editor. Instead, get a very small magnet and move it in patterns over a floppy disk.

Then again, it's not like I'm not against things like .NET.
.NET is bad.

That is all.

(I've never touched it and never will.)
Posted

Thank you for your support. .NET is incredibly evil.

 

I might be somewhere in the middle; I don't believe in using RAD tools like realBASIC or .NET, but I don't want to waste my time in ASM either. C/C++ tends to be the industry standard for a reason.

 

P.S. The older you are, the harder it is to learn. Old people are not neccesarily bad at making stories, while find it hard to learn obscure series of characters.

Posted
Quote:
Originally written by Wilfred A. Spurts:
Good coding helps, but it is not everything. Question- would you rather have a decent, unremarkable scenario made by a non-programmer, or no scenario by a non-programmer?
As a designer: the former.

As a player: the latter. I have fairly high standards on scenarios I'll play; I can't help that and would probably choose ten-centimeter spikes through the forehead rather than play Undead Valley by l33td00d.

Quote:

But even more than that, since I myself am being thrown around as an example here, people don't start off at the top- but that doesn't mean they have to stay on the bottom. Capitalism is not a meritocracy, but programming for BoA in many ways is. Maybe hard work isn't the whole pie, but if a designer wants to design, don't hold something against a tool.

For instance, when learning calculus, one can assume that a limit exists and determine the methods to reach it. Some people need to see it- I sure did. Without graphing calculators, there would be less than half of the people in the classroom who would grasp calculus as quickly as the others, but those other people now know how to do calculus (or at least that aspect of it- god knows I'm floundering with other portions) just as well as everyone else.
Invalid analogy, I'd say--because a graphing calculator visually shows you the results while you must put in the raw data. A scripting tool takes in visual input and puts out the raw data--which, for many people, leads to the "black box" mentality, where they don't want to know how something works because it does.

Quote:

Similarly, if you make a took that lets people see how it's done, they will be able to make scenarios now, and they will be able to do so in the future without the tool. How did I learn BoE? Same way I learned BoA (except with not as much time taken up in-between): I fumbled, I experimented, but even moreso, I looked at scenarios in the editor and figured out how they did that which they did. How did one-times work? I checked. How did special encounters work? I checked. If I had an intuitive manual or a device, though, I wouldn't have required half of the time and could have done it much quicker than I would have been able to otherwise.
TM, that's the best way to do it. Tools to write your code for you are not, which is the ONLY THING I'VE ARGUED AGAINST FROM THE BEGINNING.

A visual representation of dialogue trees might help some people. I've simply said that I'd not use it for a host of reasons and that I probably wouldn't add it to AVD2 because of that and technical issues.

Quote:

God. I can't believe you're really arguing that you shouldn't be making a tool.
Tools for data entry and that sort of thing? Fine. Eliminates tedium.

Tools to do your work for you? No. You don't learn that way.
Posted
Quote:
Originally written by Lemon-Flavoured Oracle:
Thank you for your support. .NET is incredibly evil.
And in other news, the sky is blue!

Quote:

I might be somewhere in the middle; I don't believe in using RAD tools like realBASIC or .NET, but I don't want to waste my time in ASM either. C/C++ tends to be the industry standard for a reason.
For important work, I use C++. For something that I'm trying to kick out the door and get into circulation, RAD tools have a place.

Quote:

P.S. The older you are, the harder it is to learn. Old people are not neccesarily bad at making stories, while find it hard to learn obscure series of characters.
Which is part of the reason behind my CallWizard concept (which was a fairly large concession in the direction of what they want, but because you *GASP!* must actually read code and understand it to use them, people hated it.)
Posted

Arenax, our discussions on AIM and your posts here do not match up. No one — except apparently m's avatar over PM — has suggested a tool that would simplify scripting to the point that it would no longer have the power of writing raw script. You're arguing against people when you don't actually disagree with them.

 

Also, no one has suggested making such a tool mandatory for making a scenario; if someone makes it and you don't like it, don't use it.

 

To make a simple analogy: you write code, not assembly language. Code covers up how the computer actually thinks. Would you say that people should learn assembly language and never C? Furthermore, would you say that people should learn machine language and write code in hexadecimal rather than learning C? After all, C hardly resembles machine language, but the computer works in the machine language and C just covers it up.

 

You are starting to sound elitist. "People should SUFFER in order to write scenarios! If they don't understand the Appendices, they are WEAK OF SPIRIT and DON'T DESERVE TO BE DESIGNERS! If I can do it, then SO CAN THEY!"

 

Arenax, stop arguing against people with whom you don't actually disagree.

Posted
Quote:
Originally written by Arenaqs:
[QB]As a designer: the former.

As a player: the latter. I have fairly high standards on scenarios I'll play; I can't help that and would probably choose ten-centimeter spikes through the forehead rather than play Undead Valley by l33td00d.
This is elitist and morally repugnant- are you somehow insinuating that if I don't know how to code, I shouldn't write scenarios? As in, if I don't know how to check a stuff-done-flag, I'm not worth being a writer? Maybe godawful scenarios are worse than none- I won't argue either which way on that point. But saying that a person who can't program can't tell a scenario-worthy story is obscene.

I will simplify this for you.

Your worst disadvantage is that some people who cling to the tools will not learn to do anything without the tools successfully.

1) This ain't 100% true, since many people will try to learn coding on their own. More creative designers who want to do more creative things will eventually figure out ways to do the stuff they wanna do.
2) This is not a disadvantage that harms any party involved- more people who would otherwise be unmotivated make scenarios.

The other disadvantage, of course, is no scenarios from those who would otherwise make 'em. You try to convince me that yours is worse.
Posted
Quote:
Originally written by Wilfred A. Spurts:
[QB]
Quote:
Originally written by Arenaqs:
As a designer: the former.

As a player: the latter. I have fairly high standards on scenarios I'll play; I can't help that and would probably choose ten-centimeter spikes through the forehead rather than play Undead Valley by l33td00d.
This is elitist and morally repugnant- are you somehow insinuating that if I don't know how to code, I shouldn't write scenarios? As in, if I don't know how to check a stuff-done-flag, I'm not worth being a writer? Maybe godawful scenarios are worse than none- I won't argue either which way on that point. But saying that a person who can't program can't tell a scenario-worthy story is obscene.
They may be able to tell a story--but not write a quality scenario. Scenarios are more than story.

Quote:

I will simplify this for you.

Your worst disadvantage is that some people who cling to the tools will not learn to do anything without the tools successfully.

1) This ain't 100% true, since many people will try to learn coding on their own. More creative designers who want to do more creative things will eventually figure out ways to do the stuff they wanna do.
What I said has held true for most members of the communities of the GCKs I've used and worked on over the past few years (ZZT and Megazeux, among others). If you give people a crutch, the vast majority of them will keep it permanently.

Quote:

2) This is not a disadvantage that harms any party involved- more people who would otherwise be unmotivated make scenarios.
Scenarios that are lacking in playability, but might have a corking good story.

Sorry, but I still want playability first. Games are not mediums first to tell a story--they are first games.

Quote:
The other disadvantage, of course, is no scenarios from those who would otherwise make 'em. You try to convince me that yours is worse.
Fewer good scenarios > many bad scenarios. Elitist? Probably. Accurate? Said Boolean evaluates to True. :p
Posted

Frankly, I think that if these tools make it easier for all the duncecaps who think that the dragons of Avernum are Motrax, Khoth, and Trogdor, so what? There are plenty of OMG LUK AT MEE!!!!!! scenarios out there for BoE, and the classical reaction has to been either to flame to bits/wait until they go away, or if the newbie shows any promise to let them work it out.

 

These editors make it easier for the idiots, but it also makes it easier for the people who are learning like to get their feet wet before the plunge, and for the veterans who just want a quicker, less tedious way of doing things. This, to me, justifies the possibility that we'll have to ignore a couple more hunks of dreck than we do right now.

Posted
Quote:
Originally written by Lord Bob:
Frankly, I think that if these tools make it easier for all the duncecaps who think that the dragons of Avernum are Motrax, Khoth, and Trogdor, so what? There are plenty of OMG LUK AT MEE!!!!!! scenarios out there for BoE, and the classical reaction has to been either to flame to bits/wait until they go away, or if the newbie shows any promise to let them work it out.

These editors make it easier for the idiots, but it also makes it easier for the people who are learning like to get their feet wet before the plunge, and for the veterans who just want a quicker, less tedious way of doing things. This, to me, justifies the possibility that we'll have to ignore a couple more hunks of dreck than we do right now.
Perhaps I'm pessimistic, but I think "a few" is understating it.

BoA is a harder system to use than that of BoE. I think users are likely to be intimidated by it, and if much of what they see is garbage, they'll be scared off before they can even get into making their own scenarios. That happened to me soon after my parents bought me BoE; I saw a ton of crap, played some of it, and tossed it into my CD caddy it wasn't until a friend of mine sent me one of the better scenarios--Nephil's Gambit, I think--that I got into it. While there are probably going to be many good scenarios for BoA, bad ones have more of an impact early on.
Posted

Arenax, it's apparent that you won't be satisfied here unless you get the last word, so I'll write one more thing here, and then remain silent. If you want to continue to pick apart what I and others write line by line without looking at the meaning of what we write as a whole, so be it.

 

You have points of view of coding, scenario creation, etc. I have different points of view on the subject.

 

I believe that many people what to tell a story. Anything (in this case scripting) that gets in the way of telling that story reduces the chance they will be able to do so.

 

You don't belive that. That's OK.

 

There is NO right or wrong here. The best we can do is agree to disagree.

Posted
Quote:
Originally written by Silence in Motion:
Arenax, it's apparent that you won't be satisfied here unless you get the last word, so I'll write one more thing here, and then remain silent. If you want to continue to pick apart what I and others write line by line without looking at the meaning of what we write as a whole, so be it.

You have points of view of coding, scenario creation, etc. I have different points of view on the subject.

I believe that many people what to tell a story. Anything (in this case scripting) that gets in the way of telling that story reduces the chance they will be able to do so.

You don't belive that. That's OK.

There is NO right or wrong here. The best we can do is agree to disagree.
Yeah, I like the last word (but mostly this is because I'm at school and have nothing better to do), but I'd like an answer to this one:

Which is more important: a well-playing scenario or one with a good story? I have to say the former, myself.
Posted

Dude. Undead Valley sucks because Micael seems to not have half an idea of what makes a scenario fun, not because he can't program worth a damn.

 

Playable scenarios also don't require huge, shiny innovations of coding. Go back to RPG Maker 2003 and die there.

Posted
Quote:
Originally written by Imban:
Dude. Undead Valley sucks because Micael seems to not have half an idea of what makes a scenario fun, not because he can't program worth a damn.

Playable scenarios also don't require huge, shiny innovations of coding. Go back to RPG Maker 2003 and die there.
1) Never touched RPG Maker (thank God).

2) There's seriously an Undead Valley scenario? ...I was using that as a stereotypical example...

...Damn.
Posted
Quote:
Originally written by Arenaqs:
Perhaps I'm pessimistic, but I think "a few" is understating it.
I think that the amount of really, really horrible BoA scenarios out there, even with some editing help, will never rival the volume of blindingly agonizing BoE scenarios, because even with an easier editor, there's some serious thinking to be done there. I just think the gains in utility and ease for everybody outweigh the fact that there will be more BoA scenarios and yes, quite a few of them will suck.
Guest
This topic is now closed to further replies.
×
×
  • Create New...