I’m very new to the forums, and have yet to publish any IF, but I am starting this thread at the suggestion and kind encouragement of @AmandaB and @Zed, so if this forum gets sick of seeing my shy username once I finally get over my stage fright, then you’ll have them to thank, lol.
The general idea is: I’m very systems-oriented, and am deeply fascinated by the idea of really pushing parser-based IF further into simulation territory. If it’s not too bold nor pretentious to say, I’d like to write IF that reaches the gameplay orbit of something like the original Deus Ex game from Ion Storm, or maybe MechWarrior 3 (I know how that sounds; I’m the one who type that in). Just stuff that’s probably really different from what’s usually out there, and that most people don’t think would work in IF. I take that as a challenge.
(Also, uh…I’m not very character-oriented. When I’m reading a story, I’m actually paying more attention to the setting that any of the characters. I’ve only read one book in my whole life where I connected with a character. So yeah, my IF is gonna be strange and mechanics-oriented, too.)
The player is presented with a goal, and a simulated environment. However they accomplish the goal is up to them; I might not realize some of the possibilities, and that’s okay, but the game should respond smoothly the whole way, at least.
I’ve tried gutting Inform 7 and TADS 3 adv3Lite, but it feels like an upward battle before I can get to the starting point, as both of these have a lot of features and systems built-in that don’t facilitate what I need to do.
So, what’s the Jess Adventure Core?
“Jess” is my other name, for those curious. It’s fine; don’t worry about it, lol. I just felt like “Joey” didn’t have the right ring to it in for an IF engine library.
The Adventure Core will be entirely its own thing. It will function as a UI, parser, simulator, etc. As an API, it won’t have an editor program. I will have to make my worlds by defining them in Java. Honestly, I’m thinking of learning Kotlin for that bit. I prefer normal Java for creating application logic, but that’s just a bit too verbose for defining data. The reason why I’m not making an editor, is because the creation of an editor will probably triple development time, and would basically be a Java IDE anyways, which is what I already have at Square One of this project. So: no editor! It’s just a stripped-down Java API.
It’s for this reason that I’m making it for my own uses first and foremost. If someone later down the line wants to use it, that’s awesome, but I feel like other systems better-suit the needs that most authors have, and we already have so many amazing authors. I’m not making the Adventure Core because I’m trying to match or outdo anything like Inform, TADS, Quest, Twine, etc. What I’m making isn’t intended to be better, it’s intended to be weird and niche, but more importantly: it’s intended to let me finally get my IF ideas in the hands of players. My game ideas have a lot of overlap, and do not behave with current technologies, so I’m making a new program to support them in.
Each game will ship with the Jess Adventure Core compiled into it (no project dev time dedicated to game files, because again that requires an editor). However, I do plan to have a user settings file created by the Core, and will be loadable and readable by all IF games I make, so you can set your preferences to get as close to your preferred runner/interpreter as possible, and any time you play any of my other stories, it should cooperate.
Goals
The simulations and systems run by my Adventure Core will likely be a lot less controlled and author-directed than other IF platforms. As the author, I will probably be outlining environment frameworks, and implementing how things generally react, but the specifics of what happens as a result I expect to be fairly out of my control in a lot of way, and will hopefully self-govern (if the framework was set up correctly).
The benefits of this is that I expect to run into fewer issues of “I forgot to put something here” or “I forgot to code this item action” or “oof this NPC does not know how to behave here”.
The downsides that part of me is masochistically-excited for are that instead of nothing happening at all sometimes, really unexpected and hilarious stuff will happen instead. The player might have a lot more agency, but the environment will, too. NOTE: This may vary as development goes on. The thing I’m trying to avoid is the player running into brick walls of “you can’t do that”, when it wasn’t implemented as an intended step of the solution.
Again, I’m not saying this will be better than the norm, because we already have a database full of amazing IF that uses convention to deliver amazing ideas and really reach our emotions. My aim is, again, to do something weird because I feel like it, and most of my game ideas work like this, and I really want to make some IF.
The other huge goal is I really need my UI and overall engine to be cooperative to screen readers. IF is a medium of game and storytelling that has quite a lot of players with varying kinds and degrees of visual impairment and disability. It is absolutely critical to me that I keep my engine accessible. When I was developing visual games with 3D graphics and stuff, I would use an app on my phone to make sure that everything is clear with different types of colorblindness and visual acuity. I intend to bring that same energy here.
What Are Some Things I’m Excited For
I’m particularly excited about “action groups”, which can be hidden from the player, enabled, or disabled. Unless an action group is shown and enabled, the player cannot use those actions. The player will also be alerted to these groups being revealed, enabled, and disabled, and this will usually occur when the player drastically changes their situation. There’s going to be a lot of possible actions, and I don’t want the player to be overloaded. A good example would be a combat actions. You would not use these actions outside of combat, so if you’re not in combat, the group would be disabled, and the player would get a notification like “Combat actions are now disabled”. Similar to actions used when piloting a large ship.
This is also going to be important, because I’m adding a window that can be pulled up to reveal a list of enabled actions for player reference, so you won’t have to guess the verbs for the whole game.
Again, I feel like these systems are out-of-place in most IF, but I want to give players the tools necessary to maximize their agency, as a lot of my games will probably not be very puzzle-oriented, where every action fits neatly together. You’ll be able to goof around quite a bit (if this works out), and it will be important to inform the player on what that entails.
Something else I’m poking around with is parkour, or the idea that by climbing on some objects, other objects are revealed to be within reach, and you can chain these discoveries together to find hidden paths to other areas.
Additionally, I would to implement a combat system and room territory system, where hostile “guard” NPCs can claim parts of a room, and block your access to those parts unless you somehow get rid of the guards.
I would like to implement a better system for handling large expanses of terrain. In particular, give the player a verb like “survey”, that lets them scope out other visible regions, and their relations to the current region they are in.
A specialized turn system will be in place as well, where some actions allow the world to take a turn after execution, while others do not, and some make the world take multiple turns before control returns to you. For example, actions which allow you to visually inspect things will not take a turn, as the player should be able to freely refresh the story prompt for vital information before deciding their next action.
Vehicles will have a lot more detail, as I plan to simulate the cockpit, allowing the player to inspect and use the controls found inside. The components of the vehicle could also be simulated as well, allowing some to suffer damage and affect performance, and the player needs to gain access to the component and swap it out for repair.
I am currently supporting autocomplete, which will be off by default, but can be turned on and have the option to visually show suggestions. More on that is described in my manic struggles here. Basically, as you type, the autocompleter figures out what action or noun you’re talking about. In the case of a noun, it narrows down which one, based on the adjectives you’ve used already, and only suggests adjectives that you’ve both not used yet, and which also apply to the nouns you could be talking about. I’m actually really proud about how this one turned out, and it’s fully-functional.
Each game will also come with a built-in notepad, which will save its contents when you save your game, allowing you to keep your notes and reminders bundled with your save.
I plan to have a skeletal map that shows the layout of the rooms you’ve discovered. Room shapes will probably not be implemented (this could change…been going back and forth on that a lot).
NPC conversations will be very much choice-based with dialog trees. This seems kind antithetical to “do whatever you want”, but I feel like the player has more agency when they can at least see what they can contribute, and not boil all conversations down to “talk about…” or “ask about…”.
I will also have a built-in UI feature that takes over the input field for anything that offers a choice. You won’t need to enter in a number and press “Enter”; you’ll be presented with a series of buttons instead. I have this mostly working already.
These are most of the stand-out things that the player would notice. I’m also going to be handling actions differently under the hood than other systems seem to. For example, an object only has certain properties if it is qualified to handle an action where they would be important. If an object would refuse an action, then it’s probably because it quite literally is not the kind of object you could do that to, and this is defined at the start, rather than at the end. So instead of creating stuff like “thing”, “decoration”, “container”, “platform”, etc, you would assigned qualifications to an object like “can be taken”, “can be pushed”, “can store things”, “can support things”, etc, and then the necessary data will also be attached to help evaluate actions for those qualifications.
On a Personal Note
I have really intense ADHD. Like, I have enough ADHD that patches of my vision don’t always update with time, as though the space where an object is located will cease to exist for a second until my brain can be bothered to focus on it and recognize that it’s there. To say my brain is constantly low on focus is an understatement like you wouldn’t believe.
So: While I have been needing something like this Adventure Core for a long time, it is very possible that I could get overwhelmed, have a whole depressive crisis over it where I burn my dreams, alter my game ideas, and return to using TADS 3 again (btw TADS 3 is so good omg; just wanna see how this goes, though).
(Also, I am DYING to see how the Linux version of Inform 7 goes, and I’m also dying for a dark mode on it, as bright text backgrounds make my brain want to explode)
It could happen. Nothing in this thread is a promise. Honestly, it’s why I don’t really discuss my projects on the Internet. However, two amazing people were interested in seeing where I’m going with this, so this is clearly doing somebody out there some good, lol. I do a lot more work when there’s less expectation!
Who knows? One day this might suddenly become a TADS 3 library. I dunno. Or I might decide to do simpler stuff (hahahaha if you knew me irl, you’d know how unlikely it is that I do anything simply).
Until I run screaming into the night and vanish from the face of the Earth, my GitHub for the project is found here.
