rl oriented scripting language features.

[Z]

Yes, the methods themselves can be done as delegates. But you also need an engine which performs the work of adding methods to objects, calling them, and removing them. This should be a part of the script engine, otherwise it could get too slow.

I don't see where co-routines fit.

[TSMI]

What do you mean by scripting language? A very high level, dynamically typed language that has an intrepeter?

I've always found the term confusing - what's "scripting" and what's "programming"?

[Xecutor]

What do you mean by scripting language? A very high level, dynamically typed language that has an intrepeter?

I've always found the term confusing - what's "scripting" and what's "programming"?

Yes, I'm talking about high level dynamically typed programming language.
It has virtual machine that executes pcode.

Yes, the methods themselves can be done as delegates. But you also need an engine which performs the work of adding methods to objects, calling them, and removing them. This should be a part of the script engine, otherwise it could get too slow.

I don't see where co-routines fit.

Event handler of multiphase event can be executed as coroutine that can skip to required phase, when needed.
For example:

Code: [Select]

func onTakeDamage(source,target,damage)
  org=damage.clone()
  skip(afterBlock)
  source.takeDamage(target,org)
end

event handler stores original damage taken by unit and, if damage wasn't blocked, source also takes this damage.
Between event start and damage blocking code original damage value can be affected by many factors.

[Z]

Between event start and damage blocking code original damage value can be affected by many factors.

In my solution each method added gets a priority, and they are executed from highest to lowest priorities, i.e., only the highest one is executed, but it can call down the next one. I can choose if a method calls down before, after, or in the middle of doing its own thing. For example, in a WriteName method that outputs things like "large rusty iron shield of flaming (equipped)", highest priorities are assigned to the most external prefixes and suffixes (large, equipped), lower ones to the internal ones (iron, of flaming), and the lowest priorities to the noun ("shield"). If I want to add an effect which consists of several parts which have different priorities (interleaved by methods gained from other sources), I just add two methods (in the example above this happens for the "large shield" which is a specific item type). I don't see how coroutines help here...

[TSMI]

For my own endeavors I've quite often considered integrating a Scheme ( its another language I occasionally dabble with ) for scripting purposes, but it always comes back to what I mentioned in my previous post in that it doesn't seem to buy me anything in terms of roguelike dev. I think its the mental gear change when switching from c++ I find too much, especially given how expressive c++ is anyway

I have too - scheme can buy you loads IMO, once you know how to get some power from it.

It may interest you to know that Guile, which was designed to embedded, has finally reached version 2.0, and is appareantly much improved.

[TSMI]

It's hard to estimate before you try
I've made some prototyping in falcon and I love results very much.
Actually I already have rich perl experience, and I know how convenient and fast script development could be.
But perl is too heavy and hard to embed.
I tried many different scipting languages, I liked some features of ones and other features of others.
Falcon is the best so far featurewise, but it's too far from release version,
but I took part in development in case I fail with my project

I don't understad what you mean by Perl being "heavy" (with resources?), but... you don't have to embed.

You can easily just write your game in the higher level language, and write modules for it in C to do the heavy lifting. I'm sure perl has a way to do this. My scriptling language of choice, Ruby does this quite easily. I didn't feel the need to embed it at all, I just made a C library of stuff that needs to be fast and wrapped that as a C module.

I don't like falcon because it's way too weakly typed. "cat" + 3 should nut return "cat3". that's just wrong and strange.

[Krice]

In wizard's quest there are over 100 effects.
Each effect have owner and most of effects have dynamically generated value(s) and some have dynamic effect description.
There are over 50 monsters and a lot of them have unique abilties that have dynamic values.
All this stuff must be saved.

So what? If you create over-complex data structures then they are going to be difficult to save and load. In my experience you can also do stuff the simple way. For example number of X don't really matter, because they are saved in same way.

If you are so sure that scripting is not needed, just ignore this topic.

There is no scripting in Kaduria either and it's supposed to become a major roguelike.. so yeah, I know I don't need scripting.

[TSMI]

There is no scripting in Kaduria either and it's supposed to become a major roguelike.. so yeah, I know I don't need scripting.

Maybe if you'd used a higher level language it'd be done by now.

[Krice]

Maybe if you'd used a higher level language it'd be done by now.

Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.

[linux_junkie]

Maybe if you'd used a higher level language it'd be done by now.

Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.

ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua.  Plus, it should be obvious to anyone, and in the professional and academic world is undisputed common knowledge, that the choice of language, as well as what tools you use, undeniably plays a large role in *any* programming project.  Choice of language and tools, coupled with the developer's proficiency in them, is critical to any project that wants to ship this century.  To suggest otherwise reveals an extreme lack of understanding of the software development life cycle.

Higher level languages, which features more machine instructions per line of code, by their very nature result in a more rapid release, whereas lower level languages take more time, as well as requiring a greater debug time.  This is why many software companies make extensive use of higher level languages for applications that are not speed critical, since speed is where most higher level languages lose their edge.

This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope.  I'd say he pretty much makes the value of scripting languages undeniable.  By coding a robust engine in C++, which uses OpenGL for rather impressive graphical effects, as well as being highly modular, he's able to add an absurd amount of content with every release, solely because of the increased productivity of working in a higher level language like Lua.

All in all, whether or not you choose to make use of a scripting language is up to you, and depends on your design goals.  But to suggest that because *you* don't use it, that it doesn't provide a huge productivity boost for others who may use it, is silly and absolutely wrong.

[Krice]

ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua.

So what? After all, you can do stuff with scripting as well.

This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope.

I think he is just damn good programmer. Nothing to do with scripting really. But I wasn't really impressed by ToME 4. It maybe has tons of stuff, but you know.. it's kind of boring.

[Darren Grey]

I think the programmer plays a more vital role than the language.  Lots of people are writing RLs in Python, but DarkGod is the only one making a big success.  Partly I think it's his experience of writing older languages that has taught him to make the most of Lua.

Scripting vs non-scripting is down to personal preference.  Both are valid tools in anyone's hands.  Certainly scripting makes many things convenient (especially submissions from community members), but if the dev is more comfortable with something else then he should stick to what he likes.

[TSMI]

Maybe if you'd used a higher level language it'd be done by now.

Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.

ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua.  Plus, it should be obvious to anyone, and in the professional and academic world is undisputed common knowledge, that the choice of language, as well as what tools you use, undeniably plays a large role in *any* programming project.  Choice of language and tools, coupled with the developer's proficiency in them, is critical to any project that wants to ship this century.  To suggest otherwise reveals an extreme lack of understanding of the software development life cycle.

Higher level languages, which features more machine instructions per line of code, by their very nature result in a more rapid release, whereas lower level languages take more time, as well as requiring a greater debug time.  This is why many software companies make extensive use of higher level languages for applications that are not speed critical, since speed is where most higher level languages lose their edge.

This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope.  I'd say he pretty much makes the value of scripting languages undeniable.  By coding a robust engine in C++, which uses OpenGL for rather impressive graphical effects, as well as being highly modular, he's able to add an absurd amount of content with every release, solely because of the increased productivity of working in a higher level language like Lua.

All in all, whether or not you choose to make use of a scripting language is up to you, and depends on your design goals.  But to suggest that because *you* don't use it, that it doesn't provide a huge productivity boost for others who may use it, is silly and absolutely wrong.

I am pretty sure the vast majority of tome4 is in Lua. also the other stuff is in C, not C++.

Just to be pedantic

[TSMI]

I think the programmer plays a more vital role than the language.  Lots of people are writing RLs in Python, but DarkGod is the only one making a big success.  Partly I think it's his experience of writing older languages that has taught him to make the most of Lua.

Scripting vs non-scripting is down to personal preference.  Both are valid tools in anyone's hands.  Certainly scripting makes many things convenient (especially submissions from community members), but if the dev is more comfortable with something else then he should stick to what he likes.

I disagree. The simple fact is the languages we are talking about are higher-level and more concise than C++. You can get more done, faster.

Pure C++ will perform better yes, but it's not that big a deal if you just code up the hot-spots in C, which most of these languages allow.

[Xecutor]

I don't understad what you mean by Perl being "heavy" (with resources?), but... you don't have to embed.

perl depends A LOT on it's modules. When you type 'use strict;', strict.pm is actually module, that resides in lib.
It's hard to make small 'portable perl' package. And naked perl have no sense.
XS is worst extension interface from usability point of view.
And using swig adds significant overhead.

I don't like falcon because it's way too weakly typed. "cat" + 3 should nut return "cat3". that's just wrong and strange.

If left side of add op is string, than right side is converted to string. IMO that's ok.
In 99% of cases when you will add something to string, you will mean "append textual presentation to string".
Having to explicitly cast things to string for this 1% of error cases is odd.
3+"cat" will raise error.