next »

[MeshGearFox]

Sup dudes. Been busy.

First and foremost, let me say this: I have a French 101 final and then I'm on summer for a month and then I have to work. During this time I'll be taking a break to hopefully do some documentation and generally get a life.

THAT BEING SAID.

New Features Since Last Time:

0. Lua scripting engine is entirely in place, probably, though it still needs some revisions and clean up. Namely, error messages are sort of crappish and I have a bunch of vestigial code that might blow the return stack or something. I'm honestly not really sure what I'm doing. And I probably need more Lua commands but whatever.

1. The game supports multiple levels and level switching, with definable exits and entrance positions and everything. Additionally, the level exit code is handled with the normal lua scripting so you can do interesting fun things with it.

2. The level's [sic] now have four layer instead of just two or one or whatever I had last time. I'm NOT entirely likely to change this although doing so would be pretty minor. The first level has to be in a folder called defaultLevel, though. I haven't offloaded stuff like that to an .ini file yet.

3. Player input is entirely offloaded to Lua, meaning it's completely easy to redefine what all of the keys do. To the extent that you could probably change the player character into a floating cursor/selector without much difficulty.

4. The actual game entity class (Instance) is STARTING to stabilize although there's one thing that's still sort of a point of contention and I may or may not a

5. Inventory system is in place.

6. Level and global game states are in place.

7. Text input is improved.

8. I'm probably forgetting stuff. One big thing is this "Instance Coordinator" class that handles collision. It now tracks collision, as per usual, but also stepping on things and touching things, although the touching stuff isn't fully implemented, maybe, because I might want it to track if the player is moving while touching the instance in question or if it moved next to or away from it..

9. Game objects have a set of properties: Name, type, a property string, and a state string. Other objects can search for them by this.

Basically it SHOULD be entirely possible to make a complete game now.

What's not done:

1. Save/Load functionality. This is the big one.
2. Shopkeeper inventories and dialogues (Sort of. They can be done as of now but I want a better method).
3. Cutscenes (This seriously just involves adding code to display a single, full screen image. And I might not implement this even).
4. Un-hard-code the aforementioned .ini file stuff mentioned above.

So, I'm sure you want something to play with. Well, here's the first two levels of Chip's Challenge, remade in BRPG.

http://www.mediafire.com/?yetkuwdxmnz

---edit---

Started to implement saving and loading although that revealed an underlying issue with my engine. Sometimes, Instances would need to store pointers to other Instances. As it stands now, they'd just be storing the memory address as an integer.

You can't really save memory address and expect them to have coherent results.

So I came up with a PointerManager class and implemented it. Basically, an Instance can Store an address to another Instance, mapping that Instance's address to its concrete, non-changing ID number. Instance's can then store the ID and access a stored pointer by it.

The pointer manager also tracks Instances that are about to be deleted and nullifies them safely so that if something tries to access a dead pointer, it's told it's dead and can deal with it.

Next task: Implement the rest of the save functionality. I need to write out the Instance lists for every level, the level state manager contents, and the contents of the list of open/released instance IDs.

---edit---

Save functionality appears to be done. Next task is loading.

After that I need to write something that lets you have a start menu. That'll be pretty trivial since it'll just involve running a lua script

[MeshGearFox]

Added in a new pointer manager system that essentially let's Instances store an infinite number of pointers (which are managed and garbage collected) while still imposing a rigid and arbitrary limit on the number of numeric values they can have.

So yeah, right now my main concern is fixing various memory leaks which I THINK from me using the lua return value stack thing incorrectly. After that I'll fix up the Lua-C++ function call error message things, do some testing, and start adding additional event triggers, a few more scripting commands, and working on the manual.

[happymonster]

I've done two remakes of the Spectrum game Chaos and the system that uses for combat works very well.

Each creature has an attack value from 1-9 and a defence value from 1-9.

Then you just do something like:

Code:

bool do_attack_calculation(int att, int def)
{
 // Add random chance values.
 att = att + ((Rand() % 10) + 1);
 def = def + ((Rand() % 10) + 1);

 if (att > def) return true;
 
 return false;
}

So a creature with the same attack as the target's defence has a 50% chance of killing it, while a creature with 1 attack against 9 defence has only a 10% chance of killing it.. As you can see the final outcome (live or die) is still expressed as a bool!

[droqen]

b-but

Those stats -- attack and defense -- are not bools.
ARE YOU MAD?! DO YOU WANT TO BREAK THIS MARRIAGE APART? think about the children

[happymonster]

Bah! Hide the stats, but have the outcome by boolean!
(It's the future...)

[James Edward Smith]

I haven't had the time to read this entire thread, but I like the idea of this game.

I've seen some discussion as to how combat would work and how you don't want body parts to just become the same as hit points would normally be. But have you given any thought to having a fairly boolean simulation of live be the health system. What I mean is, your heart beating pumps your blood which your brain and everything else needs. Your lungs fill up an oxygen amount that your blood uses up as it transports it around your body. A sort of system where certain combinations of boolean values being false leads to your death and some of them only turn false after a certain amount of time of others being false (You can hold your breath for so long, but being choked will eventually kill you, etc).

I think this could be interesting as killing different made up game creatures could be totally different. You could come up with a real reason as to why striking a slime with a sword could or couldn't kill it and why based on the anatomy you design for such a creature.

[MeshGearFox]

I actually ditched most of the ideas in the combat discussion a long, long time ago. Right now you basically just use weapons, they have a pattern for which tiles surrounding you they hit (a whip hits everything in a circle that's around you, for instance. A sword hits what's in front of you) and then if an enemy hits they die or if they have some means for causing your attack to not count, they don't die. It's sort of like Kroz or DROD in a sense.

I think this could be interesting as killing different made up game creatures could be totally different. You could come up with a real reason as to why striking a slime with a sword could or couldn't kill it and why based on the anatomy you design for such a creature.

Basically instead of stats and stuff, everything is a lua script with some other internal, engine-side stuff (such as map position and a very small number of stored variables, and a set of properties). In your slime example, the slime would have some attacked even triggered on it. And if it discovered it was hit with something with the SHARP property, it would... split in two or eat your sword or something. Whereas if you hit it with something BLUNT and HEAVY, the slime would be squished and then it would die because somehow that kills slimes.

Game's not working in a strictly boolean sense, in any case (in so much as game objects can store/track non-boolean values. Going back to the slimes, maybe they can only divide a certain number of times before dying, and each time they divide they lower some counter), although it's still statless.

Anyway, back to properties. That's what I want to code in today.

So basically, and I think I talked about this early, the two main datatypes in the game are Objects and Instances, which are instances of objects. In C++ terminology, Objects would be classes and Instances would be objects. I changed this around because I am ~a wizard~.

Objects are the immutable base things from which Instances derive, and they have two noteworthy properties--a name and a type, with name being the specific object, and type representing some generality about it. So you might have something called a long_sword that has the type sword, and then objects can, for instance, react differently two weapons of type sword or type mallet or whatever. One limitation right now is that objects can only have a single type. If I need to change this in the future, I will. I'm trying to avoid multiple types because I want to enforce some notion of using the most general type one can get away with because...

Instances can have properties. Properties are essentially mutable states, but they're a bit more general than that. Internally they're just stored in a string of characters which can, at the least, be 26 uppercase letters, 26 lowercase letters, and the 10 numbers. I'm doing this because it's sort of easier to parse while still remaining mostly human readable. Anyway, properties don't HAVE to be mutable, but they can be. I'd generally prefer type-style information be encoded with these because they are more fluid and interesting and allow, for instance, situations where the player could sharpen a mallet into a wooden axe, or blunt a sword from, I don't know, being stupid and attacking a wall a bunch. So, with the slime example again, instead of reacting strictly to *swords* by dividing itself, it instead reacts to getting attacked by anything sharp or thing. This would allow for more emergical behavior!

One limitation is that, again, you've got an arbitrary limit on the number of properties you can have, but I think I'm going to stick with this because if I allow for infinite properties it gets way too easy to just use them as ersatz stats which is not what I want at all.

Anyway, this is my current requirements analysis (in order of importance):

1. Implement the new property system. I have one in place right now and it works but it would be hard to debug if you, for instance, screwed up what properties you were trying to use. One thing I didn't mention above is that objects should be informed, via event/triggers, when they have a property altered, so that they can react to their state changing (you can actually do this already but it's sort of inelegant).

1a. Currently property checking only checks on property at a time. Implement a new systems where you can see if multiple properties are present in the property set.

2. Implement a new system for loading in object data. Currently all object data goes into one, big file. It's better if I have multiple files for this and then a single load list indicating which files to load. Originally I had this requirement as nice to have but not necessary, but realistically it would make testing easier and it'd be fairly easy to implement, as well.

3. Better error checking for Lua script calls. Currently it tells you what the error was (Wrong datatype as argument, generally) but it doesn't indicate which script generated the error, which is bad. Also I'm pretty sure I have typos in these.

3a. I'm not entirely sure I can actually do this now. I'm not sure if the LuaVM stores the name of the last-loaded script file.

4. Fill out the missing Lua functionality. I mentioned how objects have names, types, and properties above. An instance can search for other instances on the map based on all three of these, and there's several different search methods. I don't think I actually have all of those done, or at the least, they're not all tested.

4a. Added triggers for an object to see if moved under/out from under, is standing under something. Needs testing.

4b. Ability to find objects in the player's inventory matching certain criteria, as well as the ability to find the NEXT object matching some criteria if the first one isn't good enough for whatever reason (probably past the last found object or it's inventory slot in as an argument and start searching from there).

4c. Find the first/next object in a straight line from some destination position or Instance. sort of implemented but only works with N/E/S/W. Need to add NE/SE/NW/SW and the like, and an additional function to search in a bresenham linely manner from a given point/reference Instance to a specific point, as well as a a bresenham linear search based on degrees from a certain point or reference object. This would constitute a lot of functions! I might restrict searches to basically linear in cardinal or ordinal directions from a point/reference object. How did nethack handle throwing and stuff?

This is actually sort of done. See comment 12c for issues, though.

5. Create a new event/trigger for when the player enters a level. This isn't strictly necessary for what I'm doing NOW but I can see a lot of areas where it would be useful (respawning objects on re-entering a level, for instance, or handling some kind of time-of-day feature).

5a. This trigger will not fire on the level you start in when starting a new game or when loading a saved game since neither of those count as level changes really. I MIGHT modify it to add the level-entered triggers. That'd be a minor change if it turns out to be appropriate.

6. Functions that allow one instance to trigger an event on all Instances in the map matching some type/name/set of properties (for instance, create a switchplate that uses this function to open all doors in a level when it is stepped upon).

7. I have a global state thing, that tracks global states and values assigned to them, but I might want a separate global thing for passing messages between levels.

7a. Thought about how this works, no work done on it yet, though. Basically you can stick a message (an ILM) into a message handler (The ILMH) with some function. Each message contains a: recipient string, argument string, and a read flag. recipient strings can be as vague as specific as you want. To read a message, you use some function like ReadMessage(recipient_string), which returns the argument string (or other argument vars if I feel the need) of every message with that recipient_string in the ILMH, in order that they were placed in the ILMH, and then marks those messages as read. Read messages are deleted at the next level change.

This means that you never really have full control over who intercepts what messages (unless you use really specific recipient strings although that's less fun, albeit I can see doing some rather amusing meta-programming stuff with it).

Alternatively each message can have multiple argument strings.

8. I might also want to come up with a system that allows Instances to either move between maps, maintain consistent properties across maps. Essentially this wouldn't be hard to do--just copy themselves to a sort of transfer array, along with their destination map, x and y coordinates, and map layer, despawning them from the current map, then respawning when necessary. This isn't actually something that I can see myself needing NOW so much, but eventually it could be really useful. Actually, 6, 7, and 8 would be the basic requirements, again, for a time of day type system.

8a. This was taken care of the messenging system I devised for seven. still needs more testing but seems to work. All the features are in place at least.

9. Map memory. Instances would have a knowledgebase of their past couple of actions, as well as knowledge of what was in certain tiles when they last "saw" them. This would probably be tricky to do, and might necessitate a line of sight system, which I don't really want to do right now.

10. Create a level-wide script. Technically this can be done now by just sticking an Instance off the map somewhere and then turning it on, so this actually isn't that important, and probably even less so once I redo the object loading system, but in theory it would make things a little cleaner.

10a. Working on this. I have a weird error with the Lua stuff that I can't figure out, though, in terms of functionality, it's innocuous. Basically, there are five functions on a level that get called: levelCreation, levelEntered, levelGreeter, levelTurnStart, and levelTurnEnd. Creation gets called when a level is loaded for the first time, entered gets called when you enter a level (or re-enter), greeter gets called at the same time but after the initial draw loop so that you can stick entry messages into it and stuff, and the turnstart/turnend functions are basically default behaviors that get called at the start and end of every turn. So... that should be enough functionality.

10b. Nevermind, there was no bug, I'm just retarded and was seeing some other error as coming from this (the other error is a script-level thing and not with the engine. This task is done!

11. A-star pathfinding. This is last because implementing it will be boring.

12. Line of sight. No interest in doing this. Probably going to be necessary.

12a. Basics are in place. Namely, I got Libfov working after being a dumbass and trying to check null pointers for hours. So, currently, I have it set up to not draw areas the player can't see. Tomorrow I plan on implementing some kind of FindInFOV function as well as a TryForAllInFOV function.

12b. Actually, less related to FOV, but the kind of symmetry I want in my lua commands is turning into an interesting design issue. I mean sure in theory I could have dozens of different find functions, breaking down a long a few fields: What shape/pattern they find in (closest, straight line, surrounding, in FOV, etc), as well as what they uses as references (search relative to some reference object, search from a point, search from reference object to point, from point to object, from point to point, etc). But having everything like that wouldn't be practical, really.

13. Need to add functionality to display a single full-screen image if I can't do that through lua directly. This actually should be higher priority and it'd be pretty easy to do

14. Playing with the idea of having multiple inventories although this could get stupid to work with.

15. Have the message queue output to somewhere reasonable. Right now it takes up like half the game screen.

---edit!---

This is important so I'm making a big note to myself. I just found, accidentally, a rather
subtle bug where I'd hardcoded some program logic to assume that the player would always been on the second layer of a level. Generally this is true but not necessarily. so, reminder to self, make sure I don't have other stupid issues like this with hardcoding stuff in that shouldn't be hardcoded.

Also need to disable the pointer trace output...

Finally should probably move message queue output to some part where it's not obstructing the entire screen.

[RotateMe]

I love this idea, so I just gave it a try, but I have to say I couldn't find any of the concepts in the game... guessing it's just an engine test? Keep focused on your idea and make it somehow obvious to someone who wouldn't even have read the games name.

Good luck with this and looking forward to a proof of concept

P.S.: don't invest too much time in stuff like LOS or pathfinding, it has all been done by others before and you can just use theirs (e.g. the libtcod is VERY easy to implement).

[MeshGearFox]

If I remember correctly, the thing I have uploaded is the first two or three levels of chips challenge remade in my engine.

[deathtotheweird]

P.S.: don't invest too much time in stuff like LOS or pathfinding, it has all been done by others before and you can just use theirs (e.g. the libtcod is VERY easy to implement).

If I'm not mistaken, the whole point of him making this game is for learning.

[MeshGearFox]

New requirements analysis, this time for the scripting stuff.

Inventory Manipulation - At least six.
---

- Needs four functions for searching the inventory for items based on Name, Type, State, and Property.

- Needs two functions for pushing events on inventory objects in a given slot and running those events. |||| Nevermind this was already done apparently.


- MAYBE Needs function to get the display name of an inventory object. Might already be in. |||| This is unnecessary I think.

- MAYBE Needs a function for testing whether or not an inventory slot is empty, maybe. This isn't clear. I'm not sure how I handled pickup and droppage. |||| Seems to exist.

ForAll - At least four.
---

- Triggers an generic verb string action on all objects matching a certain parameter (Name, Type, Property, or State), so four actions for handling this.

Got this reduced to one, actually, by making it work like one of the aggregated searching functions below. Downside is that it might get slow with a lot of objects. Currently it's restricted to only working for active objects. If I need to restrict it more it'll only work on objects registered for collision behavior though I DON'T really want this.

If it's the test conditions making it slow (doubt it but who knows) then I could create for single-variable test functions.

Also found a subtle issue where it's possible to have inactive objects that can't reactivate themselves because inactive objects never update, ergo, they rely on some external Instance to activate/deactivate them.

On one hand, an inactive object should either be decorative or something otherwise controlled by a secondary object. If you want an inactive object-but-still-updatable object, you'd just turn of its collision then stick it off map or disable its drawability.

you can send messages to inactive objects to wake them up although this problem is probably best avoided by assuming that the level designer (me) is not a complete retard (this assumption is false)

I think I might need to write some more garbage collector functionality to kill inactive objects when pointers to them are lost.

Aggregate ForAll/Find Functions - At least four.
---

- Two functions. Find an object based on all *four* of the name/type/property/state set. Name and type can take wildcards. Standard FindClosest, plus a directed FindClosest.

- As per above, with ForAll.

- As per above, for Inventory searches.

Messenger (GILMH) Functionality - At least six. Possibly seven.
---

- Two functions to add a message to the queue and add a message to the queue if one doesn't already exist. Possibly a third for overwriting behavior.

- Four functions to read from a queue. One to read, marking all read messages as read, one to read without marking read messages as read, and then a variant on both that causes them to not read previously-read messages.

Find Functionality - 2 functions.
---

Currently, both find functions work from a reference object. Create variants that work from an x and y coordinate.

---

So, twenty functions to write. This should actually be easy since a bunch of them work from a pretty set template.

Additionally I want some other targeting functions, although these might end up waiting I try and implement libtcod. Essentially they just need to find an object based on its parameters in a straight line from a point/reference object, or tell whether or not there is an unobstructed path between two points. I'm less clear on how I want to do these, so they're of less importance.

Additionally 2, the find functions are all find closest. I might add in a find farthest functionality later but I can't think of a lot of situations I'd really want that in (and technically you can kludge it in anyway).

---
~~~~!!!Bonus Features!!!~~~~
---

1. Added a better system for updating objects in the player's inventory. Usually these are sort of in suspended animation unless you manually tell them to do something. Now, it's possible to have them do some default action, such as talking or recharging (Lilarcor, Laser Cannons, weapon heat going down from lack of use, etc).

2. Fixed a misspelling in source code (recieve -> receive).

---
FIXES
---

1. A lot of functions were returning integers which were actually pointers CAST to integers. This is not what I wanted to have happening.

2. Fixed some stupid error where the event handler and garbage collection stuff were running 4x as much as they needed to. This code's been present since like april so I can't toss this up to a time change.

2a. Actually that was correct behavior. Well, the event handler. Not the garbage collector or the other updater thing.

[MeshGearFox]

BRPG Engine is now in beta.
Done adding crap to it; going to go claw my eyes out for awhile.

http://img251.imageshack.us/img251/2080/brpgtestshot2.png

Screen showing off FOV and interface.

so, pathfinding and FOV are in, and I'm done adding new features. Only thing level to do is reorganize the Lua scripting function code to be in reasonably-named files so I can actually find these things, implement a few new scripting commands, and... rename all the existing things.

Here's a command list. I will be crossing these out as I finish them.

At (Positional Get's)
---
AtPos
InSlot

Creation
---
Create
sCreate
Copy
sCopy
rCopy (Agent of copy is whatever is used as the reference. This is ONLY for Agents copying themselves).
cString
cModdedString
cTokens

CreateInv
CopyInv
DelInv

Display
---
RedrawScreen
FlipScreen
DrawImage
--DrawMenu -- Dropped this because it's not really that useful now.

ForAll
---
ForAll
sForAll
ForAll-L
ForAll-S
ForAll-F
ForAll-V
ForAll-Inv
sForAll-Inv

Find
---
Find (Closest)

Find-L
Find-S
Find-F
Find-V
Find-Inv

Game/Turn/Flow Control
---
EndTurn
RedoTurn
QuitGame
SaveGame
LoadGame
ChangeLevel
--GetEntry // Removed. I'm not clear what this does or where it even came from.
ForceRun

General
---
Register
Unregister
Activate
Deactivate
Show
Hide
Delete

Input
---
--inputPoll // Not needed.
inputWait
inputCode

Message
---
Send
Receive
eSend
sReceive
uReceive
suReceive

Movement
---
mvAdvance
mvRetreat
mvBack
mvReverse
mvTurn
mvJump

Pathfinder Functions
---
pfPoint
pfInst

Predicates
---
pSame

pMoved
pMoving

pFullInv
pOpenSlot

pInFov
pUnblocked

pName
pType
pProp
pState

Pointer
---
Access
Store

Text
---
txtQueueString
txtPrintQueue
txtMenuText
txtInvDisplay

Try
---
Try
sTry
Try-Inv
sTry-Inv
tSuccess
tFailure

Variables
---
regGet
regSet
regMod

ctrSet
ctrGet
ctrInc
ctrDec

gsmGet
gsmSet

lsmGet
lsmSet

instCoords
instVel
instVelSet

instDisp
instName
instType
--instProp -- Not actually necessary.

instState
instStateAdd
instStateRem
instStateRpl

invSize

Sundry Fixes
----

1. Noticed that inactive objects could still receive events. This would lead to an event queue that would never run and thus get permanently full. And if said objects ever reactivated Serious Bad Stuff could happen since they'd start running a bunch of really old events.

2. pUnblocked wasn't popping values correctly. Other line-based functions might have similar issues.

[MeshGearFox]

I've been fixing various bugs prior to thanksgiving. Anyway now that it's finals week I have a lot of time to just screw around and work on this because studying is for tools. Rewrote the Lua functionality at the behest of/with the help of buick from the chatroom. Tried to improve some error messages too. I also have some odd memory usage issues which... need worked on once I identify what is causing them.

So here's a list of test cases:

A. These tests are being used to make sure events get generated and handled properly. "Handled properly" means that the associated Lua event gets called. Here's a list of events. I will be crossing them off as I test them.
    CREATION, -- Note: Still need to make sure that this triggers when an instance is created by another instance anonymously.
    CREATED_BY,
    COPY_CREATION,
    COPIED_BY,
    DEFAULT,
    DEFAULT_INV,
   ACTION,
    ACTION_SUCCESS,
    ACTION_FAILED,
    COLLISION_agent, There's some weird logical issue with this. Right now it it
    COLLISION_object, generates both a collision and touch event. This is correct
                              per the code bu I don't know if it's what I want.
   MOVED_NEXT_TO_agent,
    MOVED_NEXT_TO_object,
    MOVED_AWAY_FROM_agent,
    MOVED_AWAY_FROM_object,
          These are weird. I have no idea how they behave with objects in motion. In terms of movement between an object at rest and an object at motion they work fine, though.
To hell with it I think these work.
   **TOUCHING,/ SEE FOOTNOTE
    -- Merged from two separate events. Touching is a very passive event with no particular agency, so both objects involved in touching are effectively agents. Ergo, no need for a pair.
   STEPPED_ON_agent,
    STEPPED_ON_object,
    STEPPED_OFF_agent,
    STEPPED_OFF_object,
    STANDING_ON_agent,
    STANDING_ON_object,
   MOVED_UNDER_agent,
    MOVED_UNDER_object,
    MOVED_FROM_UNDER_agent,
    MOVED_FROM_UNDER_object,
    STANDING_UNDER_agent,
    STANDING_UNDER_object,
   STATE_ADDED,
    STATE_REMOVED,
    LEVEL_ENTERED,
    LEVEL_LOADED,  This doesn't exist anymore.

B. Scripting commands. Test to make sure each of the Lua function hooks behaves properly. This'll come next.

int loc_AtPos(lua_State *LuaVM);
int loc_InInv(lua_State *LuaVM);

////// Create Functions -- For all of these I really want to test whether they cause  
int cre_Create(lua_State *LuaVM); -- memory leaks or not, so I'll create a bunch of object
int cre_sCreate(lua_State *LuaVM); -- -s that get deleted immediately and see if memory
int cre_Copy(lua_State *LuaVM);   -- stays constant
int cre_sCopy(lua_State *LuaVM);
int cre_rCopy(lua_State *LuaVM);

int cre_cString(lua_State *LuaVM);
int cre_cModdedString(lua_State *LuaVM);
int cre_cTokens(lua_State *LuaVM);

int inv_CreateInv(lua_State *LuaVM);
int inv_CopyInv(lua_State *LuaVM);    
int inv_DelInv(lua_State *LuaVM);  

////// Display functions
int dsp_RedrawScreen(lua_State *LuaVM);
int dsp_FlipScreen(lua_State *LuaVM);
int dsp_DrawImage(lua_State  *LuaVM);
int dsp_ClearMenuPane(lua_State *LuaVM);

////// ForAll Functions
int try_ForAll(lua_State *LuaVM);
int try_sForAll(lua_State *LuaVM);
int try_ForAllLinear(lua_State *LuaVM);
int try_ForAllSurrounding(lua_State *LuaVM);
int try_ForAllInFOV(lua_State *LuaVM);
int try_ForAllVertical(lua_State *LuaVM);
int try_ForAllInv(lua_State *LuaVM);
int try_sForAllInv(lua_State *LuaVM);

////// Find
int fin_Find(lua_State *LuaVM);
//int fin_FindPoint(lua_State *LuaVM);
int fin_FindLinear(lua_State *LuaVM);
//int fin_FindLinearPoint(lua_State *LuaVM);
int fin_FindSurrounding(lua_State *LuaVM);
int fin_FindInFOV(lua_State *LuaVM);
int fin_FindVertical(lua_State *LuaVM);
int fin_FindInv(lua_State *LuaVM);

////// General
int gen_Show(lua_State *LuaVM);
int gen_Hide(lua_State *LuaVM);
int gen_Activate(lua_State *LuaVM);
int gen_Deactivate(lua_State *LuaVM);
int gen_Register(lua_State *LuaVM);
int gen_Unregister(lua_State *LuaVM);
int gen_Delete(lua_State *LuaVM);

////// Messenger Functions.
int msg_Send(lua_State *LuaVM);
int msg_eSend(lua_State *LuaVM);
int msg_Receive(lua_State *LuaVM);
int msg_sReceive(lua_State *LuaVM);
int msg_uReceive(lua_State *LuaVM);
int msg_suReceive(lua_State *LuaVM);

int msg_directSend(lua_State *LuaVM);

////// Movement Functions
int mov_mvAdvance(lua_State *LuaVM);
int mov_mvRetreat(lua_State *LuaVM);
int mov_mvBack(lua_State *LuaVM);
int mov_mvReverse(lua_State *LuaVM);
int mov_mvTurn(lua_State *LuaVM);
int mov_mvJump(lua_State *LuaVM);

////// Pathfind Functions.
int mov_pfPoint(lua_State *LuaVM);
int mov_pfInst(lua_State *LuaVM);

////// Pointer Functions.
int ptr_Access(lua_State *LuaVM);
int ptr_Store(lua_State *LuaVM);

////// Predicate functions.
int pre_pName(lua_State *LuaVM);
int pre_pType(lua_State *LuaVM);
int pre_pProp(lua_State *LuaVM);
int pre_pState(lua_State *LuaVM);

int pre_pMoved(lua_State *LuaVM);
int pre_pMoving(lua_State *LuaVM);

int pre_pOpenSlot(lua_State *LuaVM);
int pre_pInvFull(lua_State *LuaVM);

int pre_pUnblocked(lua_State *LuaVM);
int pre_pInFOV(lua_State *LuaVM);

int pre_pSame(lua_State *LuaVM);

int pre_pBorder(lua_State *LuaVM);

////// Text Functions
int txt_QueueString(lua_State *LuaVM);
int txt_PrintQueue(lua_State *LuaVM);
int txt_MenuText(lua_State *LuaVM);
int txt_DisplayInventory(lua_State *LuaVM);

////// Try Functions
int try_Try(lua_State *LuaVM);
int try_TrySlot(lua_State *LuaVM);
int try_sTry(lua_State *LuaVM);
int try_sTrySlot(lua_State *LuaVM);
int try_tFailure(lua_State *LuaVM);
int try_tSuccess(lua_State *LuaVM);

////// Turn/Program Control Functions
int gam_EndTurn(lua_State *LuaVM);
int gam_RedoTurn(lua_State *LuaVM);
int gam_QuitGame(lua_State *LuaVM);
int gam_SaveGame(lua_State *LuaVM);
int gam_LoadGame(lua_State *LuaVM);
int gam_ChangeLevel(lua_State *LuaVM);
int gam_ForceRun(lua_State *LuaVM);

//// Variable Functions.
int var_instName(lua_State *LuaVM);
int var_instDisp(lua_State *LuaVM);
int var_instType(lua_State *LuaVM);
int var_instStates(lua_State *LuaVM);
int var_instStateAdd(lua_State *LuaVM);
int var_instStateRem(lua_State *LuaVM);
int var_rInstStateAdd(lua_State *LuaVM);
int var_rInstStateRem(lua_State *LuaVM);
int var_instStateRpl(lua_State *LuaVM);

int var_instCoords(lua_State *LuaVM);
int var_instVel(lua_State *LuaVM);
int var_instVelSet(lua_State *LuaVM);

int var_ctrGet(lua_State *LuaVM);
int var_ctrDec(lua_State *LuaVM);
int var_ctrInc(lua_State *LuaVM);
int var_ctrSet(lua_State *LuaVM);

int var_regGet(lua_State *LuaVM);
int var_regMod(lua_State* LuaVM);
int var_regSet(lua_State* LuaVM);

int var_gsmGet(lua_State *LuaVM);
int var_gsmSet(lua_State *LuaVM);

int var_directGsmGet(lua_State *LuaVM);
int var_directGsmSet(lua_State *LuaVM);

int var_lsmGet(lua_State *LuaVM);
int var_lsmSet(lua_State *LuaVM);

int var_invSize(lua_State *LuaVM);

// Input functions.
int inp_inputWait(lua_State *LuaVM);
int inp_inputCode(lua_State *LuaVM);

** I took touching out as an event. Because it's not an event. It's like, some sort of mutual state. Or something. It makes no sense as something that would trigger an /event/ though.

*** Game now has better script reloading behavior.

[MeshGearFox]

Okay so while I'm still (slowly. really, really slowly) testing out the Lua->C++ functions, I came up with some new fairly useful features. Well, hopefully useful.

- Can now get an Instance's ID from within Lua. This is theoretically dangerous to actually do since IDs can get reassigned, but whatever.

- One initial issue I had is that you essentially need an arbitrary Instance to get passed as an argument to a lot of the lua functions to get access to some of the global constructs. GENERALLY not an issue but there was some stuff I wanted to do in the init.lua script that I couldn't do because of this. Changed some stuff around, and basically there are now alternate functions that can set/get values in the GSM directly, Send messages to the GILMH, and while I haven't added it yet, create and remove objects from the Inventory.

Anyway, one thing I've not really addressed yet is player death. There's nothing in-engine that really supports it since, well, I have some game-specific ideas of how to do it and I don't want the engine itself locked into any one of them. So hopefully I can do things in lua.

Basically on death the following things need to happen:

- Delete saved levels.
- Copy the original GSM values back over.
- Clear out the inventory.
- SAVE and do NOT delete the contents of the message handler. This thing goes across games. For reasons.
- Empty out basically everything in memory.
- Return to start menu.

So essentially a few things need to be done. First, I'm assuming I can handle the various save deletion things from within lua. If lua doesn't have the necessary file io/directory manipulation stuff, then... I'll need to hardcode something.

Second, I have no framework in place for emptying out all of the game data in memory. Frankly, I'm thinking of just quitting the game on death and letting the player re-launch it. Clunky but a number of roguelikes do it and get away with it. I'd like to avoid this, though.

---edit Feb 15?---

Added some checks so that success and failure responses can safely be reported to null agents.

Entries highlighted red in the list above have been tested but not documented. Additionally not ever command will be tested as some are not ones I find that useful and are mostly just there for feature symmetricality.

---edit Feb 21---

For the time being, all Find functions outside of FindInInv are on probation in terms of existing. I don't really like how they work.

---edit Feb 23---

Find functions re-implimented.

[MeshGearFox]

Kind of a setback when working on implemented the cloak of darkness as a test game.

I realized how I was handling actions was kind of wrong and not really taking advantage of some things in lua that would make them easier.

On the plus side I can remove about ten or so lua function hooks from the C++ part of the engine which should clean things up a bit. The new system would also be really easy to use if it works like I think it does.

In particular I still have no idea how to handle ditransitive verbs in a really agnostic way so that the verbs in question can act on anything in a manner that won't break if the inputs are stupid (hang cupcake on mexico) but will still produce the CORRECT results with good inputs (feed cupcake to Bill).

The 'must be agnostic about objects' part is what's hard. I think I found a goodish way of handling it with closures and continuations. Or at least a way to come up with a framework for it with closures and continuations that wouldn't require any engine level modifications to get working better.

---edit---

Except what I came up with now has sequencing issues I think WHOOPS.

[MeshGearFox]

Okay!

New verb system is in place. Short of it is that a lot of functionality got passed off to lua.

Basically, each Instance's Lua script has a function called Actions. Actions takes four arguments: the two Instance involved in the interaction, a specific verb string, and a number indicating the semantic role of the leading Instance. After that it's basically all lua.

My intent, though, is that you have a table of couroutines mapped to verb string keys, which are in turn embedded in subtables based on semantic role. And then you have verb functions that extract the relevant coroutines and run them. I am explaining this poorly but the cashness of this shit is off the chizzart, I guar-an-tee it.

Whatever, I fixed my earlier problem. There's also a system for queueing up actions to be executed later though I'm not entirely sure how this is supposed to work yet. The basic principle is that you stuff closures in a table. There's not that much hardcoded about this really.

Also the inventory is jacked up. There's all this stuff in the Level structure to prevent weird race conditions and concurrency issues. I forgot to apply those to the Inventory.

It's also not a good idea to store pointers on inventory objects since when you drop them the pointer table would get removed. And if it didn't, then inventory objects would possibly store pointers to stuff in different levels which would be really bad.

[MeshGearFox]

Bored, gonna rewrite the interaction/object model in lua as an excuse to write a parser for it because parser.

[J. R. Hill]

Awesome.

[st33d]

Fuck me. You've been working on this almost as long as I've been working on mine.

RPGs man   

[SirNiko]

This seems like a clever idea.

Reading over some of the posts, it almost feels like your game might work best as a Tower of the Sorcerer-like puzzler. Certain foes / situations require certain combinations of weapons and traits to defeat, and to get those weapons and traits you have to engage other foes / situations that will exhaust certain traits.

With a high level of transparency as to what you gain and lose for each encounter, it will become a large logic puzzle wherein the player will identify a certain goal they wish to attain and then they have to map out the proper course of action to attain the proper set of traits in order to achieve that goal.

To provide more challenge, offer multiple situations that give you similar results. As a very simple example, say you need a Spear and an undamaged hand to defeat the monster that guards the grail. There are two spears available, one which costs you a gold coin to buy and the other that results in a damaged hand to steal it. The player will have to buy the spear for the gold coin to succeed, since the second option leaves them without the proper traits to win. Naturally, you'd have many more layers to the puzzle to make it less simple.