The underscore is completely unnecessary to type considering you're capitolizing the next word in the function anyway. Just seems like a needless use of two hands when typing, as well as affecting overall typing speed. I hate typing underscores, it's the slowest thing on the keyboard. Oh God.
Well, I can take them out - it's just a naming issue. Does anyone else here have an opinion?
I find it a bit easier to read the names when they're spaced out more, but I do agree that it's a bit slower to type the underscores.
I dunno about that being the slowest thing to type on the keyboard, though. Depends on the keyboard, too.Most programming languages do not allow you to name variables the same as built-in functions.
Right now, the main problem is scope. Unlike actual programming languages, the scripts we're making here can be broken up quite a bit, and the program may not have a full list of all functions that are defined by the time it hits a possible reference - the function could be defined later in the script file, or even in another file entirely (this is once we get custom-definable functions in place) - hell, it might be written in a different scripting language even! The way it works with the parser currently is that it needs to make a decision when it hits the reference, either determining it's a variable or a function call, so we need a way to unambiguously determine this without necessarily knowing all of the available functions at that point.
In my opinion, the parenthesis is the simplest solution. It clearly marks that it's a function call (consistently with calls that do have arguments), while variable references will be obvious from their lack of parenthesis.
An alternative would be to, instead, require all local variables to be explicitly declared. This would remove the ambiguity in a different way, although I feel it's not as clean of a solution. On average, you probably wouldn't save any typing by omitting the parentheses, since you'd have to type out variable declarations and you'd still need parentheses on functions calls with args. Also, I think it makes the script a bit less clear to read, since you'll need to determine whether something is a variable reference or a arg-less function call, rather than the parentheses making it instantly clear.
Finally, while I might be able to work around this, if you forget to declare a local var under this system, it might start throwing "unknown function" errors at you, which might make it more confusing to debug.
To summarize, we can't take out the parens without adding in explicit local var declaration because a global function could be defined in another file, and the parser wouldn't know if you want a local var or a function call.
I'm not trying to force my way here, but I think we need to consider the pros and cons before switching things like this.
What do people think about this? Thoughts and suggestions?
Danmakufu doesn't require you to do that, isn't it C-based (dipping in to territory I do not understand)?
C-based programming languages all require parentheses on all function calls. Omitting the parens gets you a reference to the function itself (useful for some tricky things).
Danmakufu isn't really "C-based", it's more of a "C-look-alike". It imitates many of the syntax features of C, but there are several discrepancies.
mdScript isn't much different in that regard, really.
That is a way to use tasks, yes. It is nowhere near the only way and is now not even the usual way to use tasks. I was referring to the ambigiuty between jumping between tasks using yield; (you once said something like "not knowing which task is run before another," or something similar, forgive me if I incorrectly paraphrase considering we actually know which tasks are prioritized before others), as well as them running alongside the @MainLoop as their own thread. Are you going to follow the same idea or what?
By the nature of multitasking, you generally aren't ever given a specific order that tasks/threads are run. This can lead to ambiguity of order, but this usually isn't a problem as long as each thread keeps to itself.
My main gripe with Danmakufu's task setup is that it is, in my opinion, horribly designed. Using tasks changes the semantics of
@MainLoop from a "run this once per frame" script to a "loop here, and don't forget to
yield" script, for instance.
I have been considering adding a command similar to
yield into Musuu no Danmaku. The main difference here being that it would only affect the script using it - other scripts will continue on as normal, while the yielding script will resume execution next frame.
The biggest obstacle there is saving off the call stack (which right now is done intrinsically by using recursive calls to
Script.Run()*) and other necessary information so that it can be resumed later, while still allowing other scripts as well as other instances of the same script to run without interference.
*
Script class, in
Script.cs - contains necessary information for a script. Gets instantiated for each script of each
object type, as well as for each function defined.
Run runs the script defined in the object.
Take a gander.
Internet is being a pain right now, so I'll have to look at this another time.
Since it apparently wasn't addressed, object-object collision is absolutely ESSENTIAL. Some of the most creative danmaku of ever used object-object collision. Also, I don't mean to nag, but don't forget about common data files.
I'll stop bugging you now. =\ You're the strongest, NC.
Not addressed? It's already been implemented.
This.
For any
object type, you can define a collision script for a collision with an object of any other
object type or base type, and can also define a script for collisions with any object that isn't covered by the more specific collision scripts.
If there is demand, I can also add in a function to check if a particular pair of objects is colliding at the moment.
Important performance note for people planning ahead: collision-checking lots of things takes lots of processor. The "collide with anything" script should be wielded very carefully, and definitely shouldn't be used for types that you'll be spawning several objects of at once. It will be much better to narrow down what your object will need to check for collision with, and specify that.
For instance, an
Enemy_Shot will collide with the base type
Player (to determine when the player is hit or when a shot is grazed), and, for fancy patterns, may also collide with another specific type of enemy shot. But chances are you'll have no need to collision check an
Enemy_Shot with a
Boss or
Item (you can, but in most cases you'd have no need to).
Random question time!
Can individual scripts be made into standalone .exe files? Saves the trouble of "you must download this, then this, then put this in lib, then uncomment line 9, then..."
This has been covered before, but the current plan is that, while there will not be a "build into .exe file" option, there will be the option to "compile" a set of scripts into a single, condensed file to simplify distribution. Also, I plan on having a way of setting up the program to automatically run a script, to allow people to distribute a finished game/scriptpack/brofist extravaganza with the program together in a directory, and have it auto-run the packed script when launched. Details on this are TBD at the moment.
Oh, and I had this crazy idea that would be for way, way,
waaaay~ down the line -
An integrated content distribution system that would allow people to upload and download scripts from the program itself to a server. Add in things like rantings, sorting by author/genre/etc, automated checking for updates, etc., and it could become some crazy-awesome setup.
Of course, this would be at the bottom of the feature list. :V
