Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes
Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  Print  
  Having Java as a scripting language?  (Read 2168 times)
0 Members and 1 Guest are viewing this topic.
Online theagentd

JGO Wizard
****

Posts: 1392
Medals: 88



« Reply #30 on: 2011-11-13 23:13:46 »

I don't think making modders download a full JDK is all that much of a stretch.  Players certainly shouldn't have to.
Just my thought. I realized that I don't really need the ability to compile scripts in the actual game... >_> Stupid stupid stupid!!!

I mean.. just make it easy for yourself Cheesy I don't think performance is going to be a problem this way.
Oh, I will have lots of scripts. I'll be having lots of script hooks/functions that can be implemented by scripts and they are then called when the specified event happens. For example, to implement a life stealing attack, you would have a positive buff that gives a unit a script that has a onAttack() function implemented that checks how much damage is done and gives the unit life depending on how much damage you do.
All in all, I will probably have several hundred script functions called each game update.

There is no god.
Offline Mads

JGO Ninja
***

Posts: 674
Medals: 16


Directly directional


« Reply #31 on: 2011-11-13 23:26:13 »

I don't think making modders download a full JDK is all that much of a stretch.  Players certainly shouldn't have to.
Just my thought. I realized that I don't really need the ability to compile scripts in the actual game... >_> Stupid stupid stupid!!!

I mean.. just make it easy for yourself Cheesy I don't think performance is going to be a problem this way.
Oh, I will have lots of scripts. I'll be having lots of script hooks/functions that can be implemented by scripts and they are then called when the specified event happens. For example, to implement a life stealing attack, you would have a positive buff that gives a unit a script that has a onAttack() function implemented that checks how much damage is done and gives the unit life depending on how much damage you do.
All in all, I will probably have several hundred script functions called each game update.

I don't know. Let me be an idiot here, for a minute.
Don't make a game in java, where all the logic is in scripts, and then expect better performance than in java. Either, you keep it java and provide a compiler or you take jython, or jruby and deal with what performance you will get. It's the price of wanting everything scripted.

/endjerk.

I'm curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.

Offline avm1979

Full Member
**

Posts: 157
Medals: 10



« Reply #32 on: 2011-11-13 23:46:28 »

I'm curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.

I know that wasn't directed at me but... compiling is a huge pain for a lay modder. If you don't have to compile, the barrier of entry is really low - a text editor and the willingness to experiment. Once you make them run javac with a classpath set properly and all that, I'd think you're weeding out the vast majority of people who might otherwise be interested.

Games published by our own members! Go get 'em!
Online theagentd

JGO Wizard
****

Posts: 1392
Medals: 88



« Reply #33 on: 2011-11-14 04:55:36 »

I don't think making modders download a full JDK is all that much of a stretch.  Players certainly shouldn't have to.
Just my thought. I realized that I don't really need the ability to compile scripts in the actual game... >_> Stupid stupid stupid!!!

I mean.. just make it easy for yourself Cheesy I don't think performance is going to be a problem this way.
Oh, I will have lots of scripts. I'll be having lots of script hooks/functions that can be implemented by scripts and they are then called when the specified event happens. For example, to implement a life stealing attack, you would have a positive buff that gives a unit a script that has a onAttack() function implemented that checks how much damage is done and gives the unit life depending on how much damage you do.
All in all, I will probably have several hundred script functions called each game update.

I don't know. Let me be an idiot here, for a minute.
Don't make a game in java, where all the logic is in scripts, and then expect better performance than in java. Either, you keep it java and provide a compiler or you take jython, or jruby and deal with what performance you will get. It's the price of wanting everything scripted.

/endjerk.

I'm curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.
Uhmm, my "scripts" are obviously in Java if I use Janino/JavaCompiler. I don't expect better or even equal performance to Java, just acceptable performance for a game with lots of scripts. I've heard that one of the biggest overheads with script interpreters is calling a script / script method. My case of calling many hundreds 1-5 line script methods would therefore be a worst case scenario for interpreted script languages. I'm just trying to do this "right" the first time so I hopefully don't have to redo it.

Both Mads and Sproingie do have a point that people who want to mess with scripting and such stuff shouldn't have a problem with installing the JDK, so believe I have "solved" my actual problem here. I'll compile scripts in the map editor and save them in the files, so only the map editor will need a JDK to compile scripts. The actual game will only load the compiled scripts' class files. I will continue to keep an eye on Janino though, as implementing it in the map editor would be very nice. I'd also like to implement my stat expressions (like Damage = Strength * 3) using compiled code instead of the external expression lib I'm using right now. This would obviously not be affected by the bug(s) mentioned earlier in the Janino compiler, so I'll probably implement it when I have the time.

I'm curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.

I know that wasn't directed at me but... compiling is a huge pain for a lay modder. If you don't have to compile, the barrier of entry is really low - a text editor and the willingness to experiment. Once you make them run javac with a classpath set properly and all that, I'd think you're weeding out the vast majority of people who might otherwise be interested.
Huh I'd obviously do all the compiling in the map editor using JavaCompiler. No need to manually compile scripts. I'll then have a play button that compiles all the scripts and fires up the game with the map, and also an export function that saves a playable map from a map project with all the scripts compiled so that it can be opened by the game without the need for a JDK. The only thing that the actual modder/maker is exposed to when it comes to compiling is having to download the JDK.

There is no god.
Offline Chromanoid

Jr. Member
**

Posts: 91
Medals: 3



« Reply #34 on: 2011-11-14 11:30:30 »

If you want a JDKless alternative for Janino you might want to look at the Eclipse JDT Compiler. It is used in the popular Reporting Engine JasperReports for "scripting" purposes. Maybe you can try Groovy and similar languages that don't need the jdk for compiling to javavm bytecode as well. In a first prototype it should be easy to implement Groovy, Clojure, JDT Compiler, JavaCompiler... Then you can check performance and ease of use.
Offline avm1979

Full Member
**

Posts: 157
Medals: 10



« Reply #35 on: 2011-11-14 11:41:18 »

Huh I'd obviously do all the compiling in the map editor using JavaCompiler. No need to manually compile scripts. I'll then have a play button that compiles all the scripts and fires up the game with the map, and also an export function that saves a playable map from a map project with all the scripts compiled so that it can be opened by the game without the need for a JDK. The only thing that the actual modder/maker is exposed to when it comes to compiling is having to download the JDK.

Ah, my apologies, that wasn't obvious to me Smiley From what Mads said, it seemed like modders would have to know about "compiling", which in this case they don't. They just have to install the JDK, as you said, and the rest just magically works. My mind just didn't conflate "modding" with "map editor".

Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #36 on: 2011-11-14 12:09:20 »

Sorry, my code is currently more similar to scrambled eggs than to actual code. I basically hackingly merged two different test programs. Go figure... T_T

It's easy to reproduce though. Just create two java files, with the first one containing a method with a while(true)-loop with a break; to exit it. Then load both of them with a JavaSourceClassLoader (the while-break one first) and bam! JaninoRuntimeException!  Cry

Only just had a chance to follow up.  This is exactly what I'd tried out in Praxis without problem - just checking there wasn't anything more complicated involved.  As mentioned, I'm using 2.5.16 and the ClassBodyEvaluator.  Which of those helps I don't know.

I think the SimpleCompiler superclass of ClassBodyEvaluator can compile full Java classes too (personally I prefer using class bodies for user scripts) which might also work OK.

I realise from subsequent replies you may have talked yourself out of Janino by now, though  ...  Smiley

Best wishes, Neil

Offline impaler

JGO n00b
*

Posts: 5



« Reply #37 on: 2011-11-17 07:41:51 »

A bit late, but what about Beanshell?

http://www.beanshell.org/

It uses Java syntax too which makes it even easier.
Offline avm1979

Full Member
**

Posts: 157
Medals: 10



« Reply #38 on: 2011-11-17 11:19:29 »

Only just had a chance to follow up.  This is exactly what I'd tried out in Praxis without problem - just checking there wasn't anything more complicated involved.  As mentioned, I'm using 2.5.16 and the ClassBodyEvaluator.  Which of those helps I don't know.

I think the SimpleCompiler superclass of ClassBodyEvaluator can compile full Java classes too (personally I prefer using class bodies for user scripts) which might also work OK.

Just to make sure - are you using the same instance of ClassBodyEvaluator to compile both snippets? You have to be using the same instance of JavaSourceClassLoader for the problem to show up.

Pages: 1 [2]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.146 seconds with 20 queries.