TIGSource Forums

I've been kicking this idea around for awhile, but never made it because I didn't know how to program. Then last week I entered a strange mood and now I have a bunch of stuff done, somehow.

The original idea was to make a game using nothing but bool variables, because that would be HILARIOUS. That doesn't really seem easy to do though because after awhile you'd pretty much be programming in binary but it did give me some cool ideas.

One of the things I dislike about RPGs is the overabundance of stats. They mostly break down into completely meaningless sets of numbers that grow at completely meaningless rates. And so, keeping this in mind and working with the idea about making a game using nothing but booleans, I came up with the core idea for the game: all stats in the game must be expressible in strictly is/is not or has/has not etc.. relationships.

For example, you don't have hitpoints. Hitpoints are numbers and are therefor not allowed. Instead, you are either "healthy" or "not healthy," and "alive" or "dead." These are determined by other states represented in binary terms. Unfortunately I don't have any particularly concrete gameplay mechanics for this yet. One idea involves having body body parts that can be destroyed for various effects.

Similarly, equipment chains are fairly shallow. There are only a few weapons, all of which do the same amount of damage -- they just differ in properties. Likewise, there aren't different kinds of armor, really. Going from the body part example, a body part is either armored or unarmored, and that's that.

In terms of combat, since any effective attack is equally effective as any other effective attack, the idea is to have combat and equipment based around not on doing more damage but on increasing your likelyhood of doing damage.

Anyway, right now I'm mostly working on the engine stuff. So far I have:
* Movement.
* Tiling.
* Loading object data and instancing objects from it.
* Event scripting.
* Text output.

Not really sure what other engine level stuff I need. I'm going to start building up interactions right now and go from there.

Language: C++, using SDL as a graphics API and Lua for scripting.

And here's some cute little monster sprites (I'll tone down the brightness sometime)

(http://img526.imageshack.us/img526/1372/monstersprites.png)

November 24, 2009

Event Handler

Reconfigured the event handler to store return values on a stack. I'll PROBABLY need that later.

Began integrating Lua. So far I have a hook function for Lua to add events via lua scripts. I need to rename the event code, maybe. Strictly speaking, the Lua functions are events. The things getting added to the eventQueue are more like actions. I don't think it really matters, though. I could just name the event identifiers with a prefix indicating what exactly they are.

Instancing System

I need to re-engineer the instancing system to work as such:
The GameObject class will now be referred to as an Instance class.
The Instance class contains the following members:
* Int iID; // The specific ID for the instance.
* Int iActive; // Whether or not the instance should update/draw.
* Int iDeletion; // Whether or not the instance needs to be deleted.
* Int drawOrder; // What “layer”/order the instance is drawn in.
* Int xpos, ypos; // The current position of the instance.
* Int lastx, lasty; // The previous position of the instance.
* GameData* instanceData; // The data associated with the instance.
The Instance class contains the following methods:
* Int ID(); // Return iID.
* Int active(); // Return iActive.
* Int deletion(); // Return iDeletion.
* Void coordinates(int&, int&); // Sets the Instance object's current coordinates to the args.
* Void moveback(); // Reset the Instance object to its last position.
* Void setpos(int, int); // Set the coordinates of the Instance object to the args.
* Int update(); // Calls instanceData's update method, which takes a pointer to the containing Instance.
* Int draw(); // Draws the Instance's sprite at its position. Does NOT call a method in instanceData.


Checklist (To-do):

• Major: Add code to allow new GameObjects to take a string indicating their scriptfile and a string indicating their “stat” file in their constructor.
• Major: Add a function that allows one object/function to execute a function from another object's script.
• Minor: Work on naming conventions, especially in regards to that agent/object distinction I wanted.
• Minor: Keep making event functions till I run into issues. I need to start defining interactions and things.

The idea sounds hilarious, but is using only bool variables that much different from using stats? You're merely taking one number-based system and replace it with another.

Anway, this reminds me of my very first game written in BASIC when I was 13, using only if (and its associates), goto and print.  :D

Well, I'm not strictly using boolean values.


That's actually a major problem I'm trying to address. For instance, in the example I gave involving damagable body parts, you could say that a bodypart is just an ersatz hitpoint. NOT want I want. So I might alleviate this issue by flagging certain body parts as critical--that is, if they get hit it instantly kills whatever entity they belong to, be it the player or some enemy.

Alternatively I could make ANY hit an instakill, and then place more emphasis and fighting with items and avoiding direct combat.

I think certain body parts could be destroyed without an instakill though. Would be fun to lose hands, feet, eyes...?

I personally use obscene quantities of booleans, but shoved into a few integers:

http://www.somacon.com/p125.php

Sounds like a fun project, I wish it well.

yeah this seems like a cool idea, i'm sure that even if you don't stick STRICTLY to your boolean plan, it'll still some out as a fun game

I had an idea very similar to this where the hero would only get traits, no stats.

For example by watching a wrestling match he could get WRESTLING FANATIC, which would make him slightly better at fighting.

By saving a puppy from a well, he could get BRAVE, which would help him fight ghosts, and to save the puppy you would have to be AGILE, learned by playing on the monkey-bars, or playing basketball. ARMED AND DANGEROUS comes from finding a weapon, and INJURED or DEAD comes from losing a fight.

There would be no random battles in this game, just a series of traits to acquire until you find one of the endings, which would consist of a poster like screen saying KING OF THE JUNGLE or ADVENTURER EXTRAORDINAIRE or whatever, depending on what ending you found.

I guess I'm saying I like your game.

Okay. Was on vacation for a few days, hence the lack of updates.

As far as gameplay goes, I decided that everything would be defined in terms of its behavior, instead of, like, stats. This is sort of a natural decision given that stats had already been gotten rid of because of the whole... boolean-ness of how game objects work. What this means is that every object has a set of state flags (not so much properties, per say, as these are all temporary characteristics that can freely change) and a script (currently in Lua) which defines its interactions.

From a programming standpoint I did some neat things with how map objects are handled. Basically I wrote an Instance class which isn't anything but an abstract interface for a seperate GameData class. The Instance stores a list of all events that afflict the current map object, as well as its position information. But all the behavioral stuff is defined in a separate GameData object. This is convenient for me since it means I can essentially change the GameData thing a lot without doing anything to the Instance class, which is pretty set in stone by this point.

Also did some work hashing out how the event system should work. That's not a huge rewrite. Mostly just a fleshing out.

I'm also going with the all hits are instakill idea, because I can do some interesting things with out. I haven't really fleshed out WHAT these interesting things are, yet, but... I will!

This sounds awesome. I love the concept and I hope it goes far.

Instakill on hit = This makes me think of Warhammer which I've never played, only heard about. On every attack made, will there be a %chance of survival versus instant death? Or will it simply be death if someone gets the jump on you?

Colour me interested either way.

Sounds a lot like Bokosuka Wars! But wouldn't the %chance of survival basically be like another stat, which you'd have to store in a non-bool variable?

"But wouldn't the %chance of survival basically be like another stat, which you'd have to store in a non-bool variable?"

Exactly. This is sort of tricky and I'm trying to think AROUND this issue because it's, er, tricky.

I have a major gripe with RPGs as a whole, and that's weapon obsolescence. Like, where every weapon essentially behaves the same way, just with slightly different stats and you basically buy new equipment every new town, anyway? Yeah, I don't like that.

So my idea is, instead, to have weapons with unique properties that guarantee you get the first hit in certain circumstances. Naprimer!

* Spear - Once per turn, if the player is wielding a spear and the enemy attacks first, the enemy is killed. What this means, in a practical sense, is that if you have a spear and can lure a mob of enemies into a narrow hallway, you can kill them by just letting them throw themselves at you. On the other hand, if they surround you, you pretty much die fast. This places an emphasis on positioning.

* Various single-use disposable phase guns - You can shoot things from a distance, once. You can't necessarily AIM them though. They shoot in one direction, or in a particular pattern. A few can be aimed. Some have special affects, like taming enemies.

* Halbred - Could be invoked to wipe out a row of enemies in front of you. However, doing so leaves you vulnerable for the rest of the turn.

Stuff like that. The only one really set in stone is the spear. I REALLY like the idea behind that.

Anyway, as far as progress goes, I rewrote the loader functions. They're a little cleaner now. The next task is to rewrite the eventHandler stuff which is sort of the main core of the program and probably can't be done till I have stuff designed, first. I'm planning on writing the Lua scripts as I'd like them to appear, then write the EventHandler stuff from them.

mcc: I was thinking more along the lines of a little formula that creates a % chance simply based on various bool variables. There would be no notion of such a thing in the weapons' stats themselves (so like a "heavy" armour variable would increase survival chance by 30%, unless the weapon has the "piercing" bool)

MGF:

That sounds awesome D:

This is sound a lot like a roguelike to me now, though.

Not the first impression I got from your first post, and although it doesn't sound bad, it doesn't sound much like it's going to be showing people how an RPG (in the sense you've been talking about) can be made with bools.


And a question, will the weapons also have a % chance to kill in regular circumstances -
in the sense that there's something like a 50% base chance modified by bool combinations?

Fun fact:

The pokemon trading card game resolves all need for dice with coin flips. Some attack damage for example being a result of multiple coin flips as opposed to damage dice.

I'm ashamed to know this and no I don't play that damned game anymore  :-[

This is a very interesting project - I had an idea (well, based on various discussions and existing games) for a trait-based RPG, similar to what has been proposed already in this thread. It might still come about, although I probably won't be a total purist. It seems to be a better emulation of fairy tales and legends - you don't have 18 strength vs 19 strength, you have "tough monster" versus "cunning thief".

Bit off topic, but regarding coin flips - Armageddon Empires effectively does this: Attacker has STR 6 so tosses 6 coins (ok, dice with 3 "winning" sides) and defender has STR 4 so tosses 4. If attacker gets more heads, they win. I'm intending to borrow this system in future as it has some nice properties. Each side always has some chance of winning, and the way the percentage chance changes as the stats change is rather nice. I might dig out my excel sheet if anyone's interested.

You should do this for GAMMA 4 - make the input system Boolean as well.

I think this is a great idea.  I've actually been thinking about a stealth/ based roguelike based on these sorts of concepts.  Like, you would have a variety of weapons that served functional purposes rather than damage--for example a dagger is used to open bleeding wounds where a club is used to knock an enemy unconscious.  In the dungeon, every single enemy would be more powerful than you, so that it would be literally impossible for you win in a fair fight.  Dispatching enemies would be centered around "alert" states.  It'd be simple to kill a sleeping enemy, or one who is staring at the wall, for example.  Otherwise, you would have to use tactics to get enemies 'distracted' so they have trouble defending themselves.  For the lesser enemies it might be as simple as throwing sand in their eyes.  Others you might have to poison so that they enter a drunk-like state (or you could just get them drunk!).  I'm not sure how it would work for tougher enemies without it turning into "do x amount of things to them before you can kill them," because, then it's basically hitpoints with one extra step.

Did some thought experiments and figured out a simpler way to do the Event Handling stuff.

So I'm trying to figure out how to collision/LOS/locative stuff.

Right now I'm planning on having some "coordinator" classes. Ideally Instances only know about their state (and related data such as position, last position, events affected against them, and possibly the position they're moving too).

So, I want to offload all of the collision and LOS detection. For collision, I have a CollisionMap class which objects can register to to be considered for collision detection. Then, registered objects can update their position on the map and test to see if they're colliding with anything. Fairly simple and seems to work well.

I was thinking about trying to do something similar for LOS/FOV although I'm not sure that's the right idea or not. Basically every Instance registers to the FOV map and can update its position on it like with the collision map. Test uses some FOV calculation to see what's visible around a given object. If it's calculating off the player, it sets some flags to indicate which objects to draw and not to draw. If it's not calculating off the player, it triggers a InFOV event for every object in the Instances FOV and then it'll handle them via the lua scripts (where I'll need to do some AI stuff to make sure the Instances target the appropriate object instead of, say, going after a random piece of detritus when something is trying to kill them). (Additionally I should probably have the actual FOV checks done within lua so that I can, say, make floor tiles not check their FOV, although I'm sure it would be amusing to make a level where the floor tiles got up and started chasing the player).

So, fun with a major code rewrite! Basically I had to change how I was storing and loading objects, in addition to changing what said objects even were. The loading stuff seems to work, now (though I'm not entirely sure why, for various reasons). However in the process I broke the draw code and SDL crashes on exist now. Oh well.

TEN DAYS LATER.

Current engine.

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

I have:

* Scripting framework in place.
* Text output stuff (need to find a better way to handle some of it).
* Collision detection.
* Basically all the other stuff I had before, it's just on a better foundation now.

Cool stuff. How far do you plan to take the engine before you start on content/game features? I find that I have to work in cycles of "game" and "engine," and it becomes too easy to ignore "game" for too long and build up faulty assumptions.

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

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.

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:

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! ;)

b-but

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

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

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.

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.


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.

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 (http://doryen.eptalys.net/libtcod/) is VERY easy to implement).

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

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

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.

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.

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.

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.

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.

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.

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

Awesome.

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

RPGs man   :-X :brofistR:

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.