| View previous topic - View next topic |
| Author |
Message |
tsb
I wanna be a ballerina!
Joined: 09 Oct 2004
Posts: 23
|
 Posted: Sat Oct 23, 2004 8:38 pm Post subject: |
[quote] |
|
heh. Good luck. You're going to need it.
One of the biggest reasons I chose to embed Python was simply because that meant that I didn't have to implement a scripting language myself. That alone saved me months.
The other big reason was that I didn't (and still don't) expect to be talented enough to outdo Python. :)
_________________
—andy
http://ika.sf.net
|
|
| Back to top |
|
 |
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Sat Oct 23, 2004 10:36 pm Post subject: |
[quote] |
|
| tsb wrote: | | heh. Good luck. You're going to need it. |
Not luck. Skill. I have already implemented one Python-like scripting language, so I know what I am talking about. Since this one is Python-like and compiles to Python byte code, I can probably reuse significant parts of the Python bytecode compiler, making this one even easier.
|
|
| Back to top |
|
|
tsb
I wanna be a ballerina!
Joined: 09 Oct 2004
Posts: 23
|
| Posted: Sun Oct 24, 2004 1:27 am Post subject: |
[quote] |
|
Okay, now I'm curious. Why go to all the trouble, instead of just using Python directly?
_________________
—andy
http://ika.sf.net
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Sun Oct 24, 2004 1:58 am Post subject: |
[quote] |
|
There are a couple of features I want for my scripting language that Python doesn't provide. In particular:- I want to be able to run functions in parallel, and save the game (including the state of those functions) while those functions are running.
- Scripts often include a lot of data. Python is a good scripting language, but a fairly poor data definition language.
- I want UnrealScript style states.
- I would prefer it if my scripting language is secure against malicious scripts.
- I want to statically check which resources (i.e. graphics, sounds, other scripts) a script uses.
- I want to give scripts access to the game state without having to import the game state module.
- I want a clear separation between scripts and engine.
|
|
| Back to top |
|
|
Joakim
Tenshi's Bitch (Peach says "Suck it!")
Joined: 05 Apr 2004
Posts: 64
|
| Posted: Sun Oct 24, 2004 11:08 am Post subject: |
[quote] |
|
I didn't read all of these posts (god, you write a lot of text), but I took a look at the scripting language used in Explorations.
I am not going to talk about the engine, because I didn't really like the gui in the demo, and I might be putting the project down over something temporary. Besides, I have a big interest in scripting.
I'm sorry if I'm repeating anything already said.
I belive that a scripting language should allow for quick development, and I think your scripting language has some querks. One of them is your expression evaluator (or rather, lack thereof):
Calc {FRM_LEFT% = PERC_LEFT% * WIDTH_UNITS%}
Calc {FRM_LEFT% = FRM_LEFT% + SYS_SCREEN_LEFT%}
It would be much easier for the user to write
FRM_LEFT% = PERC_LEFT% * WIDTH_UNITS% + SYS_SCREEN_LEFT%
don't you agree? It's actually not too hard to code an infix expression evaluator.
Same goes for SetVal {PERC_LEFT%,0} which could be written as PERC_LEFT% = 0 instead (using the same expression evaluator btw).
I also fail to see the reason to encapsulate arguments with {} brackets - how come they are present?
The syntax for your IF statements seem rather odd and hard to use too:
If {PERC_TOP% <> 0}
SetProperty {CTRL_HANDLE$,top,CTRL_TOP%}
EndIf:{PERC_TOP% <> 0}
Why must you repeat the conditional after the EndIf statement?
All in all, it seems you havn't spent enough time and efford on what users of your engine will see and use the most; the scripting language.
Are you going to expand it later on, or is this definitive?
No offence you know, I'm trying to give constructive critisism (sp? oh well).
|
|
| Back to top |
|
|
tcaudilllg
Dragonmaster
Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA
|
| Posted: Sun Oct 24, 2004 9:10 pm Post subject: |
[quote] |
|
| Quote: | It would be much easier for the user to write
FRM_LEFT% = PERC_LEFT% * WIDTH_UNITS% + SYS_SCREEN_LEFT%
don't you agree? It's actually not too hard to code an infix expression evaluator. |
Have you done it? With parentheses? I have, and it was very, very difficult to conceptualize.
Math is hard. Telling a computer how to do it is much harder.
In terms of conditional statements (this is to Rainer Deyke) there need only be one flag. You do, though, need to break off the body of the conditional from the main source tree, or you're going to take an unacceptable performance hit.
|
|
| Back to top |
|
|
janus
Mage
Joined: 29 Jun 2002
Posts: 464
Location: Issaquah, WA
|
| Posted: Sun Oct 24, 2004 9:10 pm Post subject: |
[quote] |
|
| Joakim wrote: | I didn't read all of these posts (god, you write a lot of text), but I took a look at the scripting language used in Explorations.
I am not going to talk about the engine, because I didn't really like the gui in the demo, and I might be putting the project down over something temporary. Besides, I have a big interest in scripting.
I'm sorry if I'm repeating anything already said.
I belive that a scripting language should allow for quick development, and I think your scripting language has some querks. |
Most of the quirks, from my examination of them, are to allow him to skip having a lexing pass. Last I checked, his script engine executes directly from the string representation. He can just parse and run.
I'm mainly assuming this because RPGds does this as well, and he was instrumental in RPGds' early development. You may also notice that strings aren't literals in his scripting language, they're just inline with the parameters. That's probably why he has the {}'s.
|
|
| Back to top |
|
|
Joakim
Tenshi's Bitch (Peach says "Suck it!")
Joined: 05 Apr 2004
Posts: 64
|
| Posted: Sun Oct 24, 2004 10:18 pm Post subject: |
[quote] |
|
| LordGalbalan wrote: | | Quote: | It would be much easier for the user to write
FRM_LEFT% = PERC_LEFT% * WIDTH_UNITS% + SYS_SCREEN_LEFT%
don't you agree? It's actually not too hard to code an infix expression evaluator. |
Have you done it? With parentheses? I have, and it was very, very difficult to conceptualize.
Math is hard. Telling a computer how to do it is much harder.
In terms of conditional statements (this is to Rainer Deyke) there need only be one flag. You do, though, need to break off the body of the conditional from the main source tree, or you're going to take an unacceptable performance hit. |
Of course I have done it, or I wouldn't say it was easy. I have done it multiple times, in compiled as well as interpreted scripting languages.
Yes, you have to tokenize it before it becomes easy to deal with, but then it's not that hard. No cakewalk, but not that hard.
Simply keep two stacks - one that holds values and one that holds operators. Everytime you hit a constant or a variable, you push it's value to the value stack. Every time you hit an operator, you push a value representing it to the operator stack. When you hit an operator that has a lower precedence than the last one read, you simply go through each of the operators on the operator stack and apply them to the values from the value stack. For paranthesis, you can either use recursion or a stack based solution. Functions aren't too hard to implement either.
And that's just one way.
Again, since the scripting language seems to be what drives the engine, it is crucial that it is intuitive and fast to use. If it's too hard, you should probably use an external scripting language or ask somebody who knows how to do it to implement it.
It's just a suggestion, but for my part, I would never use an engine that had a scripting langauge I was uncomfortable with. Especially not if I had to spend at least half of the development coding in it...
|
|
| Back to top |
|
|
tcaudilllg
Dragonmaster
Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA
|
| Posted: Sun Oct 24, 2004 10:42 pm Post subject: |
[quote] |
|
All I really want for a scripting language is ZZT with pixel*pixel scrolling and simple math operations. <_<
(and bitmapped tiles of course)
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Sun Oct 24, 2004 11:57 pm Post subject: |
[quote] |
|
| LordGalbalan wrote: | | Have you done it? With parentheses? I have, and it was very, very difficult to conceptualize. |
Lexing and Parsing are not terribly complicated. Along with the method shown by Joakim, for the coder who wants a Lexer/Parser, but doesn't want to manually roll his own, generation utilities, such as Flex and Bison exist. And really, neither is difficult to pick up and use. Assuming that one has some sort of Unix distro, you are almost guaranteed to have a copy of these. (Or some flavor of them.)
| Quote: | | Math is hard. Telling a computer how to do it is much harder. |
No, not really. Well, perhaps if you are uncomfortable with recursive solutions, maybe. But I hardly think that "[t]elling a computer how to do [math]" is hard. Computers are intended to do math: that's their purpose. Microprocessors have been coming with ALUs and FPUs for ages, now. Everything else in mathematics is symbol manipulation, and that isn't terribly difficult. Hell, I've got a program on my machine right now that symbolically takes derivatives, and it wasn't terribly difficult to write.
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Mon Oct 25, 2004 12:24 am Post subject: |
[quote] |
|
| LordGalbalan wrote: | Have you done it? With parentheses? I have, and it was very, very difficult to conceptualize.
Math is hard. Telling a computer how to do it is much harder. |
Actually it's quite simple, even if you don't use third party tools to make things easier for you. Take a look at C++ in Action - a C++ book aimed at beginners, and their example project is a calculator program with correct operator precedence and parentheses.
|
|
| Back to top |
|
|
MyNameIsJeff
I wanna be a ballerina!
Joined: 24 Sep 2004
Posts: 22
Location: Nebraska, United States
|
| Posted: Mon Oct 25, 2004 5:25 am Post subject: |
[quote] |
|
Aside from the quirks, it's also fucking ugly.
_________________
Guile says: Go home and be a family man.
|
|
| Back to top |
|
|
exploreRPG
Slightly Deformed Faerie Princess
Joined: 21 Apr 2004
Posts: 34
Location: Baltimore, MD
|
| Posted: Fri Oct 29, 2004 12:36 am Post subject: Silly people.. |
[quote] |
|
Silly people...
The script engine within Explorations is in NO WAY intended to resemble, duplicate, be compared to a programming language. Its not a programming language its a script language. A series a simple commands to control the game engine.. that all..
Trying to make the comparison to C++, Python, or any of the known programming languages is futile and stupid. Why? Because Explorations has plugins. Any langauge that can create native code .DLLs can plugin to Explorations. Thus, expanding the script language and linking directly into your NATIVE CODE .DLL
Why did I use the syntax? {} Because it was simple to parse and dynamically change information...
For Example:
I explained that my map editor allows the data to be shifted, as well as the map size expanded. When you shift data, any map (x,y) references that were scripted has to be changed. Using a free form script language, similary to known programming languages, would make this task virtually impossible. I chose a simple fixed script language so that the relative map changes can also update the script language references.
Explorations scripts can also be transmitted and run in OnlineMode. Its not a byte-code script langauge, its more like a batch file database. And that was the intent from the very beginning.
Again, each portion of Explorations has a specific purpose. Don't compare scripting to programming. Its NOT the same. Using a engine such as IKA, only gives you "bragging rights" that your script language is Python. It doesn't actually means you'll produce a quality game. It doesn't mean you have strong data-dependancy, or interoperability.
Joakim,
Why do you even post? LOL
You all, seem to like to brag.. I personally would like to produce a quality game. While you all script forever to make your game..I'll be working on this..
http://forums.rpgdx.net/viewtopic.php?p=13076#13076
While you all are scripting a "battle system".. I'll be making my sprite AI more realistic and problem-solving.
While you create your own stats and script to support them. I'll be making a detailed story/plot with deep twists & turns comparable to the Ultima series.
To each, his own..
Tye
_________________
enlarge
"RPG Makers Come & Go, But Explorations is Forever!"
Home Page
Last edited by exploreRPG on Fri Oct 29, 2004 1:17 am; edited 3 times in total
|
|
| Back to top |
|
|
exploreRPG
Slightly Deformed Faerie Princess
Joined: 21 Apr 2004
Posts: 34
Location: Baltimore, MD
|
| Posted: Fri Oct 29, 2004 1:05 am Post subject: Sorry for the double.. |
[quote] |
|
Sorry for the double...
As Reiner Deyke stated,
* I want to be able to run functions in parallel, and save the game (including the state of those functions) while those functions are running.
Exactly one of the reasons I created my own script language. Explorations scripts(batch files) run sync & asychronously.
* Scripts often include a lot of data. Python is a good scripting language, but a fairly poor data definition language.
My data definition is already defined within the engine. So my script just has to reference the predefined data types.
* I would prefer it if my scripting language is secure against malicious scripts.
All the more reason to create your own script language.
* I want to statically check which resources (i.e. graphics, sounds, other scripts) a script uses.
Ahhh, the beauty of databases.. Explorations data dependancy allows this to occur. Exporting an object also exports the script. I could write some routines to heavily scan the script for its resource dependancies, but it hasn't been needed.
* I want to give scripts access to the game state without having to import the game state module.
Not sure what you mean here.. but Explorations scripts have access to almost every aspect of the game. Sprites, Map, and Objects. It can even control VB/Windows forms and controls if needed. So, it acts as a perfect "middle-layer".
* I want a clear separation between scripts and engine.
I wanted the same thing. The script database is a series of text scripts that are meant to be small, portable and fast executing. Storing them in a database makes them easy to search, and edit.
I wanted almost all these same things which is why I created the script engine I have. Debating about syntax, brackets and parse methods is silly, and petty. The point is, it works.. And thats all I'm concerned about.
Tye
_________________
enlarge
"RPG Makers Come & Go, But Explorations is Forever!"
Home Page
Last edited by exploreRPG on Fri Oct 29, 2004 3:42 am; edited 1 time in total
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Fri Oct 29, 2004 2:52 am Post subject: Re: Silly people.. |
[quote] |
|
Sounds like my approach is a hybrid between tsb's and exploreRPG's, giving me the best of both worlds.
| exploreRPG wrote: | | Trying to make the comparison to C++, Python, or any of the known programming languages is futile and stupid. Why? Because Explorations has plugins. Any langauge that can create native code .DLLs can plugin to Explorations. Thus, expanding the script language and linking directly into your NATIVE CODE .DLL |
I think you're missing the point here. Native code is ugly! Why would you want to write native code if you can use a scripting language? Except, of course, if your scripting language is also ugly. (BTW, Python is a scripting language. It does not compile to native code. You can't use it to write DLLs.)
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
