nice update! I still have a lot of 7DRLs to review but I wanted to poke around with the updates. GUI seems a good deal less buggy (though, I didn’t tinker with the terminal much).
I have some theories on how the scripting + uploading works, let me know if I’m off base..
the entire entity script is executed again (either always for all entities, or at least at the time of upload)
Each round when the enemies move, the step function of an entity receives as args a entity (“self”?) and a list of tiles the entity can see.
I don’t really understand how the wander code works, it seems like there’s a bit of magic sauce in there to produce a random selection of adjacent, walkable tiles.
step returns a map, which gives a game action (like “heal” or “attack”) and a tile coordinate to do it to.
Which means:
you can change the entity’s target tag (first line, usually, “player” -> some other enemy type) and they’ll pursue those instead.
enemies can’t pursue their own type, because they’ll find themselves at the center of their own FOV, and never move. I tried changing the tag for the hacked entity at the start of each call to step (“spideybro” or the like) but I must have done it wrong or ent is read only.
You can stop a food from despawning, but you can’t change the value restored (seemingly an update from the 7DRL, the health restoration value isn’t an argument the foods have anymore). (I hacked drink and dog, if it still was then I missed it.)
enemies can heal you instead of hit you, by changing the action they perform when in their “attack” mode.
I’m looking forward to some other interactions (maybe docs for the cmd output map? Could my entities perhaps use the steps, and resume their hacked programs automatically once I follow them down?)
I imagine I would eventually write scripts for an enemy to follow me as long as only “bros” (turned enemies) are around, but engage others.
I’d also like to do some stuff like “langston’s ant” or “bugs barfing pheromones onto the map” to try to literally stand wherever I spawn until somebody finds the exit. It may not require adding info to the map (just follow the left-hand-on-the-wall rule?) but multiple entities could split the search work if they had a way to communicate. An actual “wifi” or “shared map” for entities would enable other advanced behavior.
[edit:] I guess my specific requests for this idea are: some spawn ability (maybe take a filename as an argument, so I can write a ‘pheremone.:’ script) and an example for either reading/writing variables from an entity in fov, or another map passed as a variable to step which is shared by every entity and persists between rounds.
I doubt any of this would ever be necessary to win the game, but that’s not how sandboxes work…!
although the scripts aren't technically run at the time of upload, its just that uploading a script uses one of the player's energy points, which then triggers a world step to occur.
for each world step, for each entity, I first call into the its scripts "step" function passing a map that represents an entity (the format is specified in docs.: ) (since you've already played the game you might have select "restore default files" from the settings to see the changes) and an array of tiles in the entities fov. while each tile does contain the data of an entity, and you can technically change it, the changes are local to the function call. So changing the "tag" property of the entity map doesn't effect the data in the field of view. Basically, everything that goes into and out from a function callback is passed by value.
all (non player) movement is handled by the "goal" command. I find the the shortest path (A*) from the entities position to the goal and update its path which in then follows until the "goal" is overwritten, is reached, or the entity collides with another entity.
so, after "step" is called, the entity attempts to move along this path.
If a collision occurs I call into the "collide" function (added in the updated verison) which is the same as step except it contains a third argument representing the entity that is in the tile it wants to move into.
The wander code is actually very simple. Entities have a "goal" property that only exists in the map if their goal is already set. So, in the step function, I check if the entity doesn't have a goal, then I loop through every tile its field of view adding all non wall tiles to a list of possible tiles to move to, I then select one at random using the built in 'rand function, and assign the the tiles "pos" property to the "goal" command.
Then (outside the script) the shortest path from the entities position to the "goal" is calculated using A*. So even though there are edge cases where a non-reachable tile is in the field of view, if that tile is chosen the entity simply wont be assigned a path and the script will pick a different random tile the next time "step" is called.
I did change how "heal" works, so now it does take a position. The amount that it heals is now based on an entity's "strength" stat.
The main thing I forgot to mention in the docs in this update was that you can see print statements in the terminal from the scripts of entities you are connected to. So to see the exact layout of the entity map that's passed to step you can upload this script to an entity:
: step ( ent
$ ent
)
you've correctly identified the limitations. That is, there's no direct communication between entities, entity's tags cannot be changed, and you can't pass arbitrary data to entity's scripts. This is something I've already thought a lot about. I already implemented this kind of functionality in my other project that uses this scripting language so its certainly possible, but its a very different game.
I actually just started a new project based on Stuck In Rogue, that is more focused around networking. I'm planning on making it so not only the player, but every entity is able to connect to other entities and modify their scripts or give commands directly. I've been working on terminal cmds for uploading, downloading, connecting, scanning for possible connections, etc. and then all I'll have to do if allow entities to issue commands to the terminal. I also plan on including the ability to spawn items, but I'm still thinking of how that might work.
I probably wont be adding these features back into Stuck in Rogue in as the new codebase is already diverging. But I might go back and add more detailed documentation.
← Return to game
Comments
Log in with itch.io to leave a comment.
nice update! I still have a lot of 7DRLs to review but I wanted to poke around with the updates. GUI seems a good deal less buggy (though, I didn’t tinker with the terminal much).
I have some theories on how the scripting + uploading works, let me know if I’m off base..
stepfunction of an entity receives as args a entity (“self”?) and a list of tiles the entity can see.stepreturns a map, which gives a game action (like “heal” or “attack”) and a tile coordinate to do it to.Which means:
step(“spideybro” or the like) but I must have done it wrong orentis read only.I’m looking forward to some other interactions (maybe docs for the
cmdoutput map? Could my entities perhaps use the steps, and resume their hacked programs automatically once I follow them down?)I imagine I would eventually write scripts for an enemy to follow me as long as only “bros” (turned enemies) are around, but engage others. I’d also like to do some stuff like “langston’s ant” or “bugs barfing pheromones onto the map” to try to literally stand wherever I spawn until somebody finds the exit. It may not require adding info to the map (just follow the left-hand-on-the-wall rule?) but multiple entities could split the search work if they had a way to communicate. An actual “wifi” or “shared map” for entities would enable other advanced behavior.
[edit:] I guess my specific requests for this idea are: some spawn ability (maybe take a filename as an argument, so I can write a ‘pheremone.:’ script) and an example for either reading/writing variables from an entity in fov, or another map passed as a variable to
stepwhich is shared by every entity and persists between rounds.I doubt any of this would ever be necessary to win the game, but that’s not how sandboxes work…!
you've pretty much got it figured out.
although the scripts aren't technically run at the time of upload, its just that uploading a script uses one of the player's energy points, which then triggers a world step to occur.
for each world step, for each entity, I first call into the its scripts "step" function passing a map that represents an entity (the format is specified in docs.: ) (since you've already played the game you might have select "restore default files" from the settings to see the changes) and an array of tiles in the entities fov. while each tile does contain the data of an entity, and you can technically change it, the changes are local to the function call. So changing the "tag" property of the entity map doesn't effect the data in the field of view. Basically, everything that goes into and out from a function callback is passed by value.
all (non player) movement is handled by the "goal" command. I find the the shortest path (A*) from the entities position to the goal and update its path which in then follows until the "goal" is overwritten, is reached, or the entity collides with another entity.
so, after "step" is called, the entity attempts to move along this path.
If a collision occurs I call into the "collide" function (added in the updated verison) which is the same as step except it contains a third argument representing the entity that is in the tile it wants to move into.
The wander code is actually very simple. Entities have a "goal" property that only exists in the map if their goal is already set. So, in the step function, I check if the entity doesn't have a goal, then I loop through every tile its field of view adding all non wall tiles to a list of possible tiles to move to, I then select one at random using the built in 'rand function, and assign the the tiles "pos" property to the "goal" command.
Then (outside the script) the shortest path from the entities position to the "goal" is calculated using A*. So even though there are edge cases where a non-reachable tile is in the field of view, if that tile is chosen the entity simply wont be assigned a path and the script will pick a different random tile the next time "step" is called.
I did change how "heal" works, so now it does take a position. The amount that it heals is now based on an entity's "strength" stat.
The main thing I forgot to mention in the docs in this update was that you can see print statements in the terminal from the scripts of entities you are connected to. So to see the exact layout of the entity map that's passed to step you can upload this script to an entity:
: step ( ent
$ ent
)
you've correctly identified the limitations. That is, there's no direct communication between entities, entity's tags cannot be changed, and you can't pass arbitrary data to entity's scripts. This is something I've already thought a lot about. I already implemented this kind of functionality in my other project that uses this scripting language so its certainly possible, but its a very different game.
I actually just started a new project based on Stuck In Rogue, that is more focused around networking. I'm planning on making it so not only the player, but every entity is able to connect to other entities and modify their scripts or give commands directly. I've been working on terminal cmds for uploading, downloading, connecting, scanning for possible connections, etc. and then all I'll have to do if allow entities to issue commands to the terminal. I also plan on including the ability to spawn items, but I'm still thinking of how that might work.
I probably wont be adding these features back into Stuck in Rogue in as the new codebase is already diverging. But I might go back and add more detailed documentation.