TF IF engine

Authoring
1

Because I could not find an engine that would work well for a transformation game in which your ability to complete the puzzles is dependent on the state of the current state of your body. I decided to make an engine of my own. I am planning on making the entire workflow web-based because that is what I have been more comfortable with. I do not have any previous experience in implementing IF, let alone making an engine. I am currently working on a design doc listing the requirements and stages of development. I hope I am not missing anything, but I wanted to ask those who actually have some experience to essentially check my work. Anyway, here it is:

stage 1
    map:
        rooms
    movement:
        (go)[north, n]
        (go)[northeast, ne]
        (go)[east, e]
        (go)[southeast, se]
        (go)[south, s]
        (go)[southwest, sw]
        (go)[west, w]
        (go)[Northwest, nw]
        (go)[up,u]
        (go)[down, d]
        (go)[in]
        (go)[out, o]
    

stage 2
    save system
    

    
    varibles
        turn counter
        score counter
    
    PROGRESSION of CHANGES for each BODYPART
    
    stats of each body part:
        hands:dexterity: hands
    
    character creator at start
    character:
        name
        damage(referd to as wounds)
        acceptance-state(implemented as path control)
        
    ITEMS
        ITEMS atributes
            ex:type:    reflective||matte; value:weight;descriptor:furry; wet:true/false;

stage 3
    NSFW mode
        on/off (defaulted to off. hopefully this will encourge SFW games)


    creation gui for implementors

stage 4
    interpreter:
        notebook layout
            map
            inventory

note: I will continue to update this post along with the design doc. eventually when I have actual code I will link to a GitHub repository(I love open source + plus I can then use Microsoft’s servers to take a little more computing power away from AI for something actually beneficial.

3 Likes
2

Hello. For consideration, have a think about how to represent the location of the player and items. For example, items aren’t always located “in a room”, they might be related to other items (eg “in” or “on”). This could, for example, be represented as a tree.

For directions, usually, you’ll also need: up,down,in,out.

Good luck.

3 Likes
3

thank you

4

also does anyone know any ways that it was implemented in other engines for item location

5

Welcome to the site!

From your design doc, it sounds like you’re going for a parser system (or at least a system with that sort of world model)? I’m going to caution you that designing and building this sort of system is an immense amount of work. There are only a handful of parser systems that are actively used nowadays, and it’s because getting a system to the point where other people will find it useful is a difficult and often-never-ending task.

I’d recommend at least trying out some of the existing systems first, and trying to make them work for your purposes. If they don’t end up working, you’ll then know what your new system needs to do differently, and what things worked well that you’ll want to imitate.

For example, the standard way all the big parser systems (Inform (6/7/Puny), TADS, Dialog) handle item locations is with an object tree. Each object in the world has at most one parent, which is its position, but one parent can have any number of children. But in the 80s, it was more common to treat rooms and containers as fundamentally different things rather than two parts of the same system. Getting some experience with these systems will help you figure out which approach you want to take.

The main ones you might try out:

  • Inform 7 is the most popular system at the moment, though its natural-language syntax isn’t to everyone’s liking.
  • TADS is the most powerful option that lets you do just about anything, programming-wise, though it also has a higher barrier to entry.
  • Dialog is my current personal favorite, and is designed for customizability: every aspect of its parser and world model is implemented in user-facing code that you can tweak however you like.
7 Likes
6

Can you give a simple example of a puzzle that you feel the engines you looked at wouldn’t easily cope with?

5 Likes
7

Thank you for your take. I am not afraid of a lot of work. For example my other project is the PvNP problem. This project is as much of a skill builder as it is something that I genuinely believe would be beneficial, plus if it becomes my main project, I will start on an ADHD side quest and continue working on my other project. It is also a good thing for a portfolio. :laughing:

2 Likes
8

Fair enough! A lot of projects in this community are labors of love, so I don’t mean to tell you not to work on what appeals to you.

But I’d still recommend getting some experience with the existing systems first, so you can see what works and what doesn’t, and know what to borrow and what to change. In tabletop gaming, there’s a term “heartbreaker”. It refers to when someone tries one system (almost always D&D), sees the flaws in it, and decides to design their own system to fix those flaws—but without knowing about the last 50 years of developments in the field. They’re called “heartbreakers” because the usual response to them is “I see you put a lot of work into this, but you spent years reinventing a worse version of a wheel that was figured out decades ago”, which breaks the creator’s heart.

That warning doesn’t necessarily apply here, if your goal is only to make something for yourself without worrying about how others might react. But if you want other people to take interest in it, being able to say “I made this because I wanted to do X and Inform couldn’t do X” is a big help.

5 Likes
9

The engine’s purpose is for TF games, which I found IF to be a good form for that process. Sadly, there are not too many of those. It is not like I can’t use a different engine, but I know that if I make one that is more focused on this type of thing, it would be better. I spoke in a different reply more on why I am doing it, but to answer your question, I wrote this:

Basically, the goal is to have an engine where the author can easily set up how changes affect how the MC can interact and view the environment, for example, take this concept: you enter a dungeon looking for treasure, but the tunnel that you entered from has collapsed, so you know you are not going to be able to return that way.

As you look around the room that you are in you see x number of pathways. The pathways are all filled with various dangers. Some examples of which would be:

  1. A long and wide pit that you cannot see any way to cross
  2. a path that you can see has darts flying across
  3. a path that is blocked by a wall of plants, which, even though they can be damaged, they rapidly grow back so you cannot make any progress in clearing them

In the center of the main room, you see a pendant in the shape of a dragon on a pedestal.

You pick that pendant up and wear it.

you get “cursed”

[insert lengthy description of your skin turning into hard scales]

You realize that you would be able to go down path #2 because you would not be able to be hurt by the darts.

You see at the end of the path, not an exit but instead a bag of coins (or other treasure).

You take that treasure.

[insert lengthy description of your mouth and nose becoming a snout and your teeth and nails growing sharper. also you realize you have a tail]

You realize you feel a warmth in your chest. It makes you cough a little. To your surprise, you see a little burst of flame.

You return to the main chamber, and you remember hall #3.

You proceed down hall #3 until you are stopped by the wall of plants

You burn a hole in the plants with your fire breathe

the fire counteracts the regeneration.

You proceed until the dead end.

You see a set of clothes that seems like it would fit perfectly over your new form. You would not want to be seen with your clothes in shreds after all.

You wear those clothes while tearing your old ones off. You wonder why there are slits in the back of the shirt.

You realize why those slots exist when you feel an extra set of limbs growing out of your back.

As they reach their full form, you realize they are wings.

You return to the main chamber as you notice your fire must have completely incinerated the plants.

As you return to the junction, you realize that you are able to fly over the pit in path #1.

[maybe a npc interaction to close off the story, but that would require there to actually be a story]

You leave.

game finished.

10

I don’t mean to harp on this point, but I genuinely don’t think I’m understanding your example, because I don’t see anything there that can’t be handled readily by any of the existing parser systems—even retro ones like Scott Adams. What part of that can the existing systems not do easily/elegantly/with the focus you want? “You gain a new ability and can now bypass an obstacle” is a classic puzzle, so parser systems tend to have very good support for it.

(I’m also asking because I’m the head maintainer of one of those existing systems, so it helps me to understand the use cases that we’re not currently covering. I try to have a working knowledge of the various systems so that I can point people in the right direction when they ask questions, so I genuinely would like to understand what you want your new system to provide that the existing ones aren’t.)

3 Likes
11

To start off, one of the primary things I want out of this is an easy(er) system for making this specific genre of game.

Basically, my plan was to set up a system built around the player’s state. Such as, instead of the implementer putting a hard-coded condition like

if (user_has.includes(firebreath)):
     plant_wall= "can be passed"

sorry for the python. I despise Pseudocode.

the Implementer can say

if (attribute.breath = fire)
   destory(plant_wall)

Does that make more sense?

Also, I know this setup would be more useful if I intend to eventually make a no-code GUI for it.

12

in inform6:

if (object.breath == fire) {
     destroy(plant_wall);
}

in dialog:

($Object has breath $Breath)
(if) ($Breath = #fire) (then)
     (destroy #plantWall)
(endif)

are you SURE you’ve looked at the existing systems, 'cause this is, literally, all they do.

5 Likes
13

TF games - transformation games? I did not dive deeply into Flexible Survival or Trap Quest (both are sex games), but I’m pretty sure (could be wrong) they use mechanics of transformation. As most AIF, they are nitty-gritty on the body parts implementations, and in FS these certainly can have transformations.

I’d like to ask the question that others have been asking, but to phrase it differently: what is it about the other systems you’ve tried that convinced you that it’s not easy/possible to achieve what you want in them?

So far, I think the only thing is an existing system for limbs, forms, etc. Such a system can, I think, be implemented in most (all?) of the major IF languages around. You’re basically changing the state of stuff, and changing responses to suit that. The initial skeleton to hang this on may take some work, but… if you make an IF language for this, you’ll be having the same amount of work plus all the work of making an IF language.

Consider that, for instance, you can make an Inform 6 or Inform 7 extension that has this framework. Then all you have to do is add the extension to whatever new project you wish.

2 Likes
14

Whilst not disagreeing that you can probably write this in existing systems; in fact, almost certainly you can. The point is whether or not you want to. Because, although they come with a lot, you have also the baggage and the drawbacks (deployment comes to mind).

If your standard IF requirements are simple, then perhaps it makes sense to brew your own “simple” system, and instead concentrate on making the specific tools for your genre more comprehensive.

ie a specialised system.

Perhaps you don’t really want a parser at all? Would choices be sufficient? If so, a choice system is fairly easy to roll.

Then there’s the “world model”. You can build a really simple, but surprisingly effective world model from a single container tree.

For example;

  • Everything is an “object”, including locations, items, the player etc.
  • All objects are “in” another object, except the world “root”.

So the player is in an object, which is your location. That location is in another object, and so on.

For example, you have a house. This has rooms; hall, dining room, lounge etc. These three objects are in “house”. “walls” are in “house”, so they are in all rooms. The player is currently in “hall”. Inventory is simply objects “in” the player.

Not a lot of coding to do this. AI could even do it. After that, you can work on the specific unique features of your system, and importantly, your games!

1 Like
15

As an author experienced with AIF and body-parts/anatomy, I know Inform 7 can do this.

Pseudo-code, and it does require work, but it’s basically like:

A nose is a kind of thing. One nose is part of every person. 
your nose is a nose. your nose is part of the player. Understand "my nose" as your nose when incorporated by the player.

A lengthy wooden nose is a nose. It is off-stage. Understand "my nose" as lengthy wooden nose when it is part of the player. ['incorporated by' and 'part of' are synonyms]

After wearing Pinocchio's amulet:
     now your nose is off-stage;
     now lengthy wooden nose is part of the player;
     say "Now I bet you won't tell a lie.";
4 Likes
16

I’m afraid I don’t really see the difference between these two. Most systems can do both.

But again, my goal is not to discourage you from working on what you want to work on. Far from it! If you’re enjoying building the system, then go ahead and do that.

Most systems do this one of two ways.

More modern systems (Inform, Dialog, TADS) tend to use an object model. The player, items, rooms, they’re all objects, and objects are organized into a tree (each object has three pointers: “parent”, “first child”, “next sibling”). The exact relationship between parent and child (“on”, “in”, “worn by”, etc) can either be specified on the parent (“this object is a container so all its children are ‘in’ it”) or on the child (“this object is ‘in’ its parent”).

More retro systems (Scott Adams, I think Adventuron too?) tend to use a room model. Items and rooms are fundamentally different things. Each item has a “location” property that’s either a room or the player’s inventory. These systems are simpler to implement, but there are a lot of things they can’t do (e.g. putting items in containers).

5 Likes
17

With all due respect I never said I did. I know I can make it work with an existing one but my goal is to make a engine that is easier to make these things in. I have stated my purpose in other replies.

18

Thank you. Truly thank you.

19

I say no to AI. I’d rather do the work myself and ask actual living beings for advice along the way.

8 Likes
20

Fwish-zooom!

That was the sound of my respect for you shooting up.

2 Likes