| |
A dump of long-term ideas for Verge. Displaying 1-12 of 12 total.
1
Overkill
|
My long-term plans for Verge:
* Rip out VC. It's bringing the engine down, by limiting the API to a mess of int handles, and token-delimited strings. I understand that some people still use VC, but Kildorf is working on a VC->Lua compiler, and that will hopefully be able to substitute effectively.
* Discard the "script engine" interface in C++ code (which essentially is just VC's library minus the interpreter, and Lua as a second-class citizen), and write everything using Lua's API instead.
* Rewrite the Lua v3 API as a more modular system since we don't have to bend to VC's rules. This should be faster, more modular, and more friendly to use. It would still likely be possible to make a classic Verge API based on whatever new API comes out, by simulating int handles or whatever weird things you think you need.
* Rip out weird libraries that don't need to be there anymore, like the file library (Lua has an io library of its own, and packfiles in Verge aren't really that handy anyway), dictionary library (Lua has tables which are superior), string library (Lua has its own strings), socket library (Use something like luasocket instead), CallFunction/GetString/GetInt (Lua can dynamically get attributes without having a system like this (can just index _G[name] instead to get fields dynamically), and Verge itself can use _G[name] to lookup dynamically or have C API things like luaL_ref to keep handles to arbitrary objects where needed).
* Add true callbacks to all Hook routines, so that they take functions rather than strings naming functions.
* Remove the need for an autoexec script. Lua doesn't need an entry-point function, since the program itself is an entry point and is executed in order anyways. Currently, it's already possible to do everything outside of an autoexec().
* Merge entities and sprites into one system that lets you use CHR or image files, with or without a map, but with certain behaviours (obstructions, zones) disabled when the map engine isn't active.
* Remove int handles in favor of proper userdata with true garbage collection.
* Remove token-delimited strings in favor of proper tables of information.
* Stabilize audio engine hooks into audiere (audiere itself is stable, but the library isn't being used correctly currently.
* Remove FMOD. This will mean that everything in the engine can be statically linked, no more .dll to run Verge. And it means that Verge games can be sold commercially (if you wanted) without paying for an FMOD license.
* Replace SDL dependency on Mac and Linux with appropriate slightly lower-level stuff (Carbon + Cocoa, GTK + X) to grant more flexibility and allow things like fake fullscreen for low-res, multiple windows, ability to later have OpenGL windows that can be resized without nuking a GL context.
* Refactor code to be less coupled with global state, and instead.
* Clean up OS specific libraries. Abstract various WM-handling things into interfaces that each OS implements separately.
* Clean up image library. Make it possible to eventually mix hardware on-screen and software off-screen rendering.
Comments? New features would be nice, but not as a high of a priority yet. First I think Verge needs to clean up its act and improve its stability and long-term maintainability. Removing VC and other "dead" code and rewriting the scripting interface is a critical step in that direction.
Posted on 2010-11-23 19:42:58
|
Overkill
|
Firstly, TYPO:
* Refactor code to be less coupled with global state, and instead try to have well-divided classes that don't trample on each other.
ALSO:
* Maybe come up with a style guide for writing Verge code, so there isn't this mash of different naming conventions and curly-brace on same line/next line, and we have less of a weird mix of procedural C-like mess and C++ code. Not that there's anything wrong with multi-paradigm, just... some systems could be better written.
* Remove this weird prefixing going on with filenames (what does the a_ or g_ mean in a_image.h or g_script.h?) and use a multiple folder structure. We should highly consider that for OS-related libs, since the Windows and Mac implementations of things are usually fairly disjoint.
* Ugh, we might need to keep a file library, or somehow patch Lua's internal io lib, since Lua just uses native endianness rather than swapping as required. But then again -- maybe not. Since even today's Macs are little-endian now, removing most of the worry unless we consider porting to exotic platforms. Also we could just make the people using binary io do the conversions themselves, by specifically constructing ints from the smaller bytes and such.
Posted on 2010-11-23 20:00:11
|
Kildorf
|
I know this is actually a new feature, but it would be small and imminently useful:
* Allow a command line param to load a different CFG file, and add CFG directives to switch what your main code file is. We can default to verge.cfg and system.lua as before, but this would let us build tools with Verge to run inside a game directory without having to have multiple copies of the engine sitting around.
Posted on 2010-11-24 05:43:50
|
Overkill
|
I like that idea. Makes it easy to plop tools in the same directory as Verge.
Also had an idea, and one that'll attempt to remedy the map trampling-the-globals idea to an extent:
Remove the need for string names of events in the map file. And remove the pointless concatinating of the lua script into the map file on "compile". Instead, like with the autoexec removal proposed, have the map script itself be the map's start event. And the script can return a table that hooks all the events for other things, like entities and zones.
Something like this: map.lua:
spawnPlayer(13, 72)
fadeIn(30)
local function talkToHermit(event)
textbox("Hermit: oh ho! It's been a long time since I've had a vistor!")
end
local function stepOnSpikes(event)
textbox("Yowch!")
end
return {
zones = {
healFountain =
function(event)
flash(v3.RGB(0, 255, 0))
healPartyFull();
textbox("HP and MP fully restored")
end;
spikes = stepOnSpikes;
};
entities = {
hermit = talkToHermit;
};
}
Note that this is a table with a zone event table inside and a entity event table inside. Both of those event tables store references to functions directly, instead of strings naming functions. These event tables are also in scripts instead of map formats, so they can be swapped for other events on the fly at runtime, and also for development, you can change them without having to crack open a map editor just to update some scripts.
You'll also note from the above, I use the entity/zone name to find its data. I think we should move to a dual system where either the id or name is acceptable. ids are more useful for dynamic entities/zones, and names are most useful for specific static, hardcoded entities/zones. Note that lua treats '1' and 1 differently, so '1' would be an entity name, but 1 would be an entity id.
I'd move to also remove start x, start y from map properties in favor of "tags" that can be read in from a script, so you can have: 1) multiple start points with names 2) tagging of 'waypoints' for pathfinding purposes. 3) giving spawn points for entities that are there for special events, like warping in Stan and Galfrey in front of Darin's house in Sully.
EDIT: another thing, the event argument. Instead of having global event variables, we should just pass information as an arg to the event function you're calling. If the event doesn't need the info then it can safely leave out that argument, too (Lua is okay with calling a function with more arguments than it accepts -- where it discards them, or calling with less arguments than it accepts -- where it fills in with nil).
Posted on 2010-11-24 17:32:05 (last edited on 2010-11-24 17:45:04)
|
Overkill
|
Note that this can be rewritten in several ways, including:
spawnPlayer(13, 72)
fadeIn(30)
local script = { zones = {}, entities = {} }
function script.entities.hermit(event)
textbox("Hermit: oh ho! It's been a long time since I've had a vistor!")
end
function script.zones.spikes(event)
textbox("Yowch!")
end
function script.zones.healFountain(event)
flash(v3.RGB(0, 255, 0))
healPartyFull();
textbox("HP and MP fully restored")
end
return script
Which is perhaps more elegant looking than my other example.
Posted on 2010-11-24 20:05:05 (last edited on 2010-11-24 20:07:50)
|
Goldenrod111
|
I am not sure if anyone has said anything about this, or if it is even possible with the way the engine is coded, but:
* Add the capability to change the map without breaking off the running of future code.
Even if it is just conditional placing, the one place I probably consistently call some line of code is right after a new map is loaded, even if it is just to conditionally place my characters.
I apoligize for posting something when I have no idea of how to make it work, and when I currently have nothing but a way to color code in Notepad++ posted!
Posted on 2011-02-06 23:59:07
|
Kildorf
|
No, that's a totally reasonable request. I've thought the same thing myself. I believe it hasn't been seriously tried for yet because the engine sort of relies on one map only being loaded at a time. Not saying it can't be changed... but it's not trivial either.
That said, I've recently added a new hook, HookMapLoad(), which lets you override Verge's normal map loading function call stuff. Whenever a map is loaded, it will just call the supplied function instead.
Once we get around to putting together an official release, you'll be able to use this. If you're willing to brave the depths of github you can get it in the more recent versions of https://github.com/Bananattack/verge3/. You might have to start using Lua though... unfortunately my VergeC replacement is not ready for real use yet. :(
Posted on 2011-02-07 06:10:07 (last edited on 2011-02-07 06:10:40)
|
Overkill
|
In Lua, it doesn't actually switch maps until you break out of all loops and functions. It isn't really that great either, but it thankfully lets you do a bit of logic after a v3.Map() call.
The map system in Verge really needs reworking at some point, to actually allow multiple maps.
Warning unrevised dump ahead:
Specifically, now that v3 is planned to be Lua-only at its core, we should to eventually make it so that map scripts are proper modules that don't trample over global vars. In Lua 5.1, we can setfenv on a file chunk I think. Only this will cause new problems, since it will mean limited access to globals outside, except for reading (which can be done by metatable indexing), unless we expose the enclosing globals table explicitly. Maybe not as _G, but something else, so to distinguish the map's global environment from the system's global environment. After all, if we allow direct write access of the parent environment through __newindex, then we have the same problem we have now, map functions being able to overwrite globals.
Alternatively, we could not have a separate global environment, but instead, use locals as intended, for functions with map-only access. Possibly have a table value that's returned at the end for allowing code outside the map to access specifically exposed events and data (this table could of course be modified by the map events too after it's returned, and the outer code would reflect these changes, since tables are pass-by-reference). This is simpler to write code to handle, and incurs less runtime overhead.
I'd say (in the long run) make a map into a userdata object, with its inner environment (which is populated by either the separated-module-like-method or the simpler return-a-table ideas discussed above) stored in a map attribute. Remove CallFunction and the like entirely -- since all attributes can be looked up dynamically in Lua anyways. Make it so that ShowPage doesn't update the map (because this means that there must only be one map, or you need a global list of maps in-engine, messy), and instead only process hooks and controls. If you want to update maps, use the particular map's update method. Make all layers, zones, and entities become userdata objects as well, that can be created on the fly and attached/removed from maps. Remove the concept of a global camera, in favor of a camera object that you attach to a map.
We should do a lot of things, really. But yeah, okay I think that's enough dump.
Posted on 2011-02-09 23:01:08 (last edited on 2011-02-09 23:05:19)
|
rafael_esper
|
* Make the maps circular, i.e, when you walk toward the west you can see and walk to the east portion of it. I suggest: no circular (ex: dungeons), horizontal (just east-west) and horizontal+vertical (east-west and also north-south).
* VGM playing support (see specific thread).
* Document all the current V3 with Lua feature, so the newcomers could actually create their games without too much frustation (it's not my case, as I'm here since the first release, but it was really useful to print out the first Verge manual).
Posted on 2011-03-01 22:36:10
|
mcgrue
|
maps that wrap can be solved with a script! Kildorf, do you have that demo hanging around? We should upload it for reference.
Posted on 2011-03-09 00:20:35
|
Kildorf
|
Grue! Not right now. I think Sully uses it for the overworld though, doesn't it?
And unfortunately, it requires you to prepare your map in just the right way... I wonder if there's any way we could get around that now. Hmm hmm.
I am looking forward to the day that I have time to work on tools and the engine again.
Posted on 2011-04-26 08:13:00
|
Keast
|
* Make the activation radius for entities changeable.
Posted on 2011-04-28 05:26:10
|
Displaying 1-12 of 12 total.
1
|
|
