1) for a bunch of conditions (first time you speak to the NPC, you have complete a quest, ...) select the first dialog.2) for this dialog, parse all the choice possible and filter them with other conditions (items, god/evil character, ...)3) let the player make his choice.4) launch actions associated with the choice (get an item/coins, exit conversation,...)5) select the next dialog for the choice and repeat from 2.

The only utility of a script engine that I see is if you have a game designer who is not a programmer himself and it's that person who do all the quest/dialog.

If I'm right the script engine will just call Java method() and it's those methods who will execute in your game. So the script only act as a wrapper to make it easier to understand. But you could also make this "wrapper" directly in java.

Since I'm feeling generous, asking "how do I do a conversation" is meaningless by itself. What exactly do you want to do? Show some text? Let the user pick multiple-choice replies? Type a text reply themselves? What are the possible outcomes during/after a conversation? Player takes damage? Player gets an item afterwards? Player gets an item only if they pick the right choice? Player unlocks a mission or quest? Player completes or advances a quest?

Once you've answered the above and decided what you want you'll be able to actually make an intelligent decision of where to go next. And if your answer is "all of the above" then 1. you're probably aiming too high and 2. I'm going to agree with Bonbon-Chan that you'd probably need some sort of scripting language to pull off that degree of flexibility.

The only utility of a script engine that I see is if you have a game designer who is not a programmer himself and it's that person who do all the quest/dialog.

If I'm right the script engine will just call Java method() and it's those methods who will execute in your game. So the script only act as a wrapper to make it easier to understand. But you could also make this "wrapper" directly in java.

Anyway, I'm not perfectly sure about it so tell me if I'm wrong.

Hardcode dialog is not a good idea in my point of view. It can be stricky to make correction. You can of course do it all store in compiled java classes (It will be easier at start and it depend on what you want to do). That's why I said "You may need one" and not "You should use one". It is a start to think about it.

I tried it sometimes ago in my Pong game. It work fine but I realized that it wasn't of any helps and ultimately just slow down my development, so I drop it.

WARNING : I had a problem back then using Groovy. That problem was that I wasn't able to include the Groovy lib in my webstart distribution. So, the user couldn't run the game unless he has Groovy manually installed on his computer... It was probably just me who suck with including external library but you could check if it's a real issue before doing any extensive work.

Hardcode dialog is not a good idea in my point of view. It can be stricky to make correction. You can of course do it all store in compiled java classes (It will be easier at start and it depend on what you want to do). That's why I said "You may need one" and not "You should use one". It is a start to think about it.

I know that most adventure/rpg game use a scripting language, but I have yet to understand the use of it for a java developer. The only advantage that I see for us is that we can change the game directly while it's running with a scripting language. This might be usefull for elaborating a story and making quest as you can test your game and make the change while you are playing.

The only problem with that is that you must think about if you really need it, because to be able to modify the game while it's running (by including a scripting language) you will have to implement a good architecture to support such a feature, which could possibly be a lot of work.

Like I said before the other big advantage of a scripting language is that it's easier to learn than a language like java. So to help non java developer do some work on your game (like writing quest) you can set up a scripting language for them. It's more realistic to expect that they will learn a simple scripting language than Java.

But if you already know java AND you are working alone AND doesn't need to modify the game while it's running, don't learn one. Seems like a waste of time.

If anyone has a good example of the utility of a scripting language in a game I would like to see it.

You really don't want to hardcode java code for every NPC in your game. You're creating an ugly dependancy between the world (which should be defined entirely in data files) and your code. Ok you could write some kind of plugin architecture so you can bundle compiled classes along with data files but then you've got the hassle of writing the plugin system and having to compile your now separate script code independantly of your game. Or you could just use an off-the-shelf scripting language and have it all done for you plus no hassle of an extra compilation step.

I think you're misunderstanding the benifits of a "simpler" language for scripting rather than doing it in java - scripting languages are generally more expressive and let you get your ideas and logic down with a minimum of fuss and boilerplate. Java can be very, very verbose when you just want to knock out a quick level script. Contrast with how simple and readable something like JRuby can be which performs the same logic.

If you only need simpler instructions (like displaying emotes, walking to different positions, etc.) I made an engine before where the string was parsed before being displayed, to the effect that anything that started with = did something, and == displayed =. So like =w was to do a wave emote and =m 5 10 would move 5 pixels right and 10 pixels up. Pretty simple and easy to write.

I think you're misunderstanding the benifits of a "simpler" language for scripting rather than doing it in java - scripting languages are generally more expressive and let you get your ideas and logic down with a minimum of fuss and boilerplate. Java can be very, very verbose when you just want to knock out a quick level script. Contrast with how simple and readable something like JRuby can be which performs the same logic.

I got to agree that I might be underestimating the benefits of a "simpler" language. But I got some things to add to that.

When I first start to learn Groovy I was amazed by how much simple it was to write code with it than with Java, especially when I just want to test a quick code. That's a given, scripting language are very simple and makes coding easier. But, there is a problem. They are like 50 times slower than direct Java code. So, there is just no way you can make an entire game only with a scripting language.

The solution to this problem is to embedding your script code into the rest of your java code. So you will use Java for the part of the code that require fast speed and use your script language for where speed doesn't matter. Embedding is very simple and straightforward but still add more complexity to your program. You got to put that embedding code everywhere you need to call your script code and you must make sure that speed won't be an issue.

Metadata and script code sure are really great things but they are too often the bottleneck if you abuse of them. Best way to avoid that bottleneck is to load all the data provide by the script in java class at the initialization. That way you can both have the simplicity of a scripting language and the speed of Java.

Problem is that you need to make the scripting code + the loading code that transform your script in java code.

That could simply be replace by java code (which could be very similar to the code use to store the data from the script).

In conclusion, it's true that scripting language are easier and it's faster to write code with it. But you must also consider that using 2 language together add to the complexity of your program.

If you only need simpler instructions (like displaying emotes, walking to different positions, etc.) I made an engine before where the string was parsed before being displayed, to the effect that anything that started with = did something, and == displayed =. So like =w was to do a wave emote and =m 5 10 would move 5 pixels right and 10 pixels up. Pretty simple and easy to write.

It is very easy to introduce bugs that way - don't mean using an engine but the way you describe behaviour.

depending on your standard your trying to set - id opt for looking for something fancier. But in light of the current norm and that one probably has time constrains...

What ever you do - apply good software practises and make sure your stuff is loosely coupled so given that your solution doesn't pan out / scale you can replace it with something better.

Mr_Light is right that the way I mentioned doing this is definitely not the "best" way, and absolutely not the most extensible way. I admittedly had to resort to some hackery to get the movement thing working, but it's not too bad. The big problem with it, in my opinion, is that it's quite slow, so if your game needs any sort of processor it's going to be a big hit - at least if you did it how I did, which was to parse the string for commands every time it was drawn.

But the main reason I did it that way was for the level editor so that people making custom levels could easily do something like, "Hello there, mister! =w" rather than needing to deal with a complicated emote system.

So it's a weak approach but will certainly do for simple applications and is very quick and easy to implement.

This is pretty interesting. I'm going to be working on npc dialog soon and I think I will hard code it. I don't think that's going to be that much of a problem as long as it's easy to find and change things. I'm thinking of using an npc class with an abstract method called talk() or something and then write extended classes for each character with the dialog and actions taken. Since classes are alphabetic in my IDE, I can just use a prefix to get them to all group together. This will be for a small game, however.I've already come across this with things like "attack" that have to be so different from character to character that the object oriented method really seems to work the best.

It will be an applet game, so pretty small. I'm not sure how many npc's but I don't think it will be a problem. Aside from class names, I don't see how it adds much. I'll just use a "Z" prefix so all the characters are always last in the class list.

It will be an applet game, so pretty small. I'm not sure how many npc's but I don't think it will be a problem. Aside from class names, I don't see how it adds much. I'll just use a "Z" prefix so all the characters are always last in the class list.

Surely a much less ugly approach would be to put them in their own package (or sub package)?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org