Hi all,

I have dipped and waded in Verge over the last couple years, and I first off want to say the Lua is a great idea! Lua's flexibility for creating and organizing software architecture through its use of tables/metatables makes for tons of coding flexibility, hence, better code for writing battle engines with. Here's the thing:

vc is a plotscripting language--a beautiful one at that, with perfect abstraction for plotscripting, but it isn't engineered towards developing say, developing engines--a custom map engine, battle engine, etc. like standard scripting languages are.

• Lua provides the most awesome and well-formed syntax for declaring data in scripts--perfect for better game dev without needing custom file formats for everything. This is because one of Lua's prime purposes is to use scripts for configuration files. It was designed to do that.
• Lua is also well-engineered for developing UI systems, battle systems, and systems in general because of the features that functions and metatables provide.

That being said, let's look at the whole point behind verge:

Verge is a FF (final fantasy) clone engine. Verge is most ideally suited to developing RPGs of the final fantasy or similar style. It actually is the most well engineered free engine (I have seen) suited to final fantasy style RPGs, architecturally. Every feature in Verge complements the 2D RPG developer. In this the the developers have a thing of perfection, more or less.

The thing is, many people use verge for things other than creating FF clones, and this turns a perfect plotscripting language, vc, into a must-work-around-or-hack situation, because now vc has to be extended with arms and legs to allow it to script battle engines and other things that were not part of the original intent or design of vc, at least, not from an engineering perspective.

To climax, decide. Decide the future scope of verge--FF clone engine, or generic 2D game engine--and then you will be able move in some serious good goal-based direction.

If you decide to go with generic 2D game engine, here are a plethora of what I believe are good ideas:

1. Use Lua scripts to implement the map/entity system, and provide only the basic graphics, sound, input interface to Lua.

Gues what that does: now any joe game developer can customize the map engine, etc. to their own liking--change the file format, use isometric maps, even procedurally generated maps can be coded!

2. You could even do the same thing with chars--script the char engine, so that the functionality is not only there, but it is customizable, extendable, adaptible.

3. You could even script a default battle engine as an extra goodie!

4. Then you could unify the in-game map editor capabilities with the Lua-scripted map engine, like everyone wants to do!

Just think of the possibilities! And it means that the Verge exe is smaller, and it is not as much to maintain!

I disagree that Verge has been a "clone" engine. It's always just been a 2D engine oriented towards making RPGs. The option to make other genres is there though, or at least has been, Verge 2 and onwards. VergeC is ugly, I admit. But it is still powerful, put in the right hands.

Lua isn't without its own issues either! No implicit local variable scoping, so if you assign a variable without declaring it local, it becomes global. Whoops. No way to iterate through table keys with nil values, which can be useful when printing debug information and you don't necessarily know all the keys in the table. The number 0 is not false, it's true, as is any value besides false and nil, even though 0 and false are known to be connected in several programming languages (or at least errors are made when trying to coerce other types to boolean). There are no +=, *=, -=, ..=, etc operators. The standard Lua library is fairly crippled and small, so you have to embed all the features it lacks. Lua arrays (tables) are 1-based, but the C arrays embeded in Lua will likely be 0-based.

I've been working with Zeromus on a middleware wrapper package for LuaVerge, to make interfacing with the primitive VC-style library a nicer experience and to better use Lua's feature set. I just mashed together a function that uses a bunch of metatable junk so that I could create classes with properties (instead of blah:SetAttr(5), you get write blah.attr = 5). This is important since there are a number of Verge variables that are embedded in Lua, and unlike built in functions, you can't just point to them, because changes to the some wrapper's variable won't affect the Verge variable unless there's secret __index/__newindex voodoo to do it. It's going pretty cool so far. Hopefully it'll be done before the next release.

Quote:Originally posted by Biggs

The thing is, many people use verge for things other than creating FF clones, and this turns a perfect plotscripting language, vc, into a must-work-around-or-hack situation, because now vc has to be extended with arms and legs to allow it to script battle engines and other things that were not part of the original intent or design of vc, at least, not from an engineering perspective.Funny, I don't recall having to work around or hack anything in order to make Kambou. But then, it's already well documented that I am a lunatic. Who knows whether my memory is reliable or not.

Overkill, your points about Lua are noted, however, syntax errors are minor issues to me. A programmer is a programmer. Personally, I feel that syntax errors are the programmer's job to get into the habit of avoiding, and the compiler's job to catch them when it can. It's just an initial learning curve, but after that, then the language's real limits from its paradigm, design, and functionality hit you, and those you can't change (except in the case of VergeC, if you are up for a that particular challenge), but alas, I agree--local variables should be implicit, and global explicit, or both explicit.

The difference between 0 and nil is a theoretical issue, IMO, but I know your frustrations. I kinda' like what Lua has done though--0 is a valid integer value, which takes up space and nil is nothing, or [UNDEFINED], which means "doesn't exist". It can turn the annoying verbosity of exception handling and error-prevention code into succinct, unobscure code that still is theoretically sound and can still run, because, i.e. the 'proper return value' of a function for invalidly given, or non-existent parameters, doesn't exist. To illustrate:

(division by zero means error)

>>3/0
!halt: EInvalidOp "invalid floating point operation...please contact the program vendor"

vs. (division by zero means [undefined], which is null)

>>3/0
null
>>print(3/0)
"UNDEFINED"

If you know where I'm goin'. Heh, heh, heh.

Nice work on the Lua binding *grinning* I like it.

Thanks for the responses everyone. I'm glad for the feedback.

What? Nah, Lua has a plenty large userbase. Or at least, does now with lots of game development applications.

For developers, it's the perfect candidate, since it's lightweight, fast, and has a very simple-to-use C API. It's very easy to bind things and to manage garbage-collectable data, no reference counting like Python.

For eager script kiddies, it is full of amazing flexibility through its table data structure, and mild amounts of syntax sugar. It .

SWIG is certainly neat, but it's not ideal because of the volume of legacy code (including VC) that Verge needs to continue to support at a reasonable level.

Anyways, a lot has changed in a year, too (this is an old thread, hey).

LuaVerge's new API has been thrown into the engine (that we really need to release), and it removes the dependencies on Luabind. So, we've sadly broken compatibility with Lua Verge since last engine release. If you use vx (my Verge wrapper), you won't notice much difference, though!

We've essentially got everything there, backend-wise, except we need more demos/games that use LuaVerge, and a lot of tutorials to help out.

Anyway, if you really want Python for Verge. ika (which uses Python) was once called Verge 2.7! It's evolved on its own, since. Yep.