This update is actually an entire overhaul of the NIFE engine. It will use the old code wherever applicable but the point of it is turning NIFE into a saner general use text engine.
The major upgrades here are:
A saner codebase that uses ASD to prevent gigantic amounts of read/write bloat.
An inherent instancing system that allows for both single player experiences and templated game styles (I'm assuming these are separate but it would be nice to come up with a system that incorporates both). Instanced boss battles or whatever would also be nice. Additionally, having "parties" should be instanceable as well, so you can play an MMO game with a select group of friends and have permissions to add/remove/promote/demote players accordingly. You should also be able to be in multiple instances simultaneously database-wise, though for sanity purposes you'll be locked to a single save file for pure SP worlds.
Broad support for procedural ("virtualized") areas and entities, based on my heavy work in this arena over the past 5 years.
A saner interaction system focused on the actual entities rather than the actions (though both should be supported really). So you should be able to pour a potion from the list of potions directly.
Item amts should be supported, while still allowing for uniques. I've had separate opposite problems with NIFE and shatterloop and a new system would fix both issues.
Some new feature system that focuses on UX, rather than NIFE's system of being a base engine with a bunch of plugins tacked on. I'm thinking there will be different engines in play for different types of NIFE games, though you can totally import whatever you want. There are some definite issues with rooms getting clogged up with vehicles and item lists getting clogged up with instances of them that need to be addressed. You should be able to manage a player's instanceof items, but it shouldn't be the default UI. Lots of cleanup needs to happen in general.
The actual player should entirely be JS, so that gameplay is smoother.
Full Pouch Support. Pouch's social / journaling features should ideally be a central pillar of NIFE. Room-specific social interaction is definitely something supported out of the gate.
Events and Conditions (and Procedures more generally) should be inherent and should also be saner to manage -- It helps to think of them as a Scripting system. It doesn't need to be particularly robust, to avoid the inner platform effect, but it should support basic commands and conditions to enrich overall gameplay.
When NIFE v6 is done , I should be able to advertise it all sorts of ways. That's really the goal here -- NIFE in its current state is somewhat unusable outside of the original bounds of the adventure engine, which is no longer in use.
Obviously will want to find and implement whatever features I had planned for NIFE v6 and v7 where applicable.
Overhauls to Combat that allow both player-turn-based type actions and more real time ones. Different games will have different combat systems obviously -- there should be some variety here and it should be modular so I can make additional ones and hook them in.
There are three game formats, which influence the way instancing is handled:
Endless -- Classic NIFE mechanics. A single long-running game. Useful for long-running campaigns, living worlds, casual play, MMO exploration, etc.
Format -- A template system where different game formats are constructed (for example aliens or braaaaains) and individual games end at some point. Games will get the template at the outset and there are tools that allow you to randomize things and make adjustments, or just revert to the template if you really fuck up.
Experience -- A full engune is set up as a template, and then individual games will instance it when players sign up solo or as a group (or players can be dynamically added). Some tools can also randomize things or use procgen tools, but the focus with these kinds of games are more the puzzle and Metroidvania elements, which only have to be set up once. Testing here will instance the game so you can interact with things without altering the template world state permanently.
Instancing framework
Working from the ground floor here, the best solution to instancing is just cloning the entire database and changing all fields accordingly -- I'll be rebuilding the database and all future tables with this kind of thing in mind. This prevents complicated checks or handling property changes.
Events, Conditionals and Machines will be bundled together into more of a general-purpose scripting system. Also Procedures.
There should be some kind of Filtering system in general use so you can search for stuff in long lists much easier -- it would be in play here as well so if you're targeting a Mine for example you don't have to look at every single mine in the entire game. The filter system should definitely show every filter you've already applied (specific rooms for example).
Both events and conditions should be double indexed -- you should be able to see what triggers it and also what gets triggered from the relevant entities.
Conditions work like they currently do except you should be able to group them recursively into AND or OR clauses so you can optionally make more complex logic.
Event triggers should be really really robust -- entering a room, using an item on a room, whatever. Basically if you can make an action in any capacity you should be able to attach an event to it. Events can also require conditionals.
Events Meta
Events can have some optional additional functionality for more complex logic:
They can be grouped recursively, where groups follow their own logic.
A group can happen sequentially or out of order.
Chances can be attached to individual events or groups.
A group can trigger N effects within the pool, sequentially or (by default) out of order.
Groups or effects can have an amt attached so that they happen N times. This can either rerun the full brick or it can just retrigger things that have already been determined.
This kind of complex functionality (and complex conditionals) should optionally be plugins and/or otherwise organized out for UX purposes.
Wherever possible, engines should handcraft their own events to cut out some of the legwork for Hosts. Experience systems come to mind here -- while you *can* make XP distribute to skills according to a character's class manually, it would make much more sense to use the plugin.
Procedures
Procedures are events that you can run as a Host to cut some of *your own* legwork out. They can again have conditions attached, and if they don't trigger you'll see why, or if they do you'll get a readout of what was changed.
There should be some kind of native Rollback engine that reverts database entries to an earlier state. This would tie into Procedures but also all hosting actions in case you completely fuck something up. Some kind of log should allow you to see changes you've made -- this should maybe delete after 24 hours or something to free up db space.
Delays
Events or groups can have delays attached -- in the case of a sequential grouping, you'd need to make a grouping if you want a set of events to trigger after a delay (and these can have subdelays).
Delays can be based on real time, one of the in-game time engines, or a certain number/type of actions / etc. It should be pretty robust but ideally plugined for all the really nitty gritty ideas.
Hanging events or groups can be removed with other events, extended or shortened.
Speaking of which, all of the meta above can *itself* fit into events. Fitting it into conditions is probably a nightmare.
Meta can also be attached to enchantments which can be removed or altered accordingly. There's probably one hell of a deep rabbit hole here so I'll need to form-fit most of it for good UX.
Characters -- can carry Items, interact with everything and move around different Rooms. Players occupy a Character.
Vehicles -- a hybrid of a character and a room. Characters can drive them or use various actions the character could, but also has Room(s) attached to it.
Fixtures -- physically identical to characters but don't move around and have more specialized roles. They don't necessarily store items natively.
Items -- Stored on Characters or in Rooms. Do various things when interacted with by Characters.
Entity layers
Entities of all types can have sublayers and metalayers. They can be recursive as well:
Subrooms -- subrooms are classifications of a room that group things together. Moving subrooms doesn't count as a movement action, and subrooms aren't locked or whatever. It's helpful for categorizing together large rooms.
Metarooms -- Categorize together rooms into areas, regions, etc. Makes filtering lists a lot easier, as well as properties being inherited from the region more generally.
Metacharacters -- groups of characters that can move or act as a single unit.
Metavehicles -- same deal here.
Subitems -- Items can have different components. This can be recursive.
Subcharacters are handled by portable containers, while metaitems are synonymous with subitems.
Item System
Items can either be homogeneous or unique.
Homogeneous items have an amt, and collecting them will update the amt rather than create new items. Pulling some amount out into a stack (for gifting or whatever) will however create new amted item entities.
Unique items can share a name but have varying properties, so they're stored individually. Picking up two Flaming Swords will fill two item slots.
Inventory Management
There should be multiple Engines in play here depending on what the game engine needs exactly:
Infinite -- obviously, no limits whatsoever.
Slots -- Items fill slots and if you run out you can't store additional items. There can be stacking rules here, and they can be set different ways -- like maybe arrows cap at 20 but sticks caps at 100. If this is in play, the max is indicated on the items areas. These caps can also be modified in various ways.
Weight -- Items have a certain value of weight and containers/inventory have a weight cap. Items can potentially have 0 or even *negative* weight, but in that case containers might not themselves be able to drop below 0.
For simplicity, only one storage engine can be used.
Equipment can optionally interact with various storage engines, either contributing to totals or not. If they do, equipment slots can optionally not affect the system and this all can of course be altered by effects.
Interactions are really a two-way thing. Or more, depending on what is happening exactly. So everything whatsoever should be indexed and you should be able to access an action through any of those endpoints.
For example, Pouring a Potion on a Weapon is a player character action, something you can access from the potion in question, or something you can access from the weapon in question. The usual limits still apply however (like limits or an inability or other conditions).
There should be some way of creating custom actions that hook into this system, utilizing events and #hastags to do whatever you want it to do. Having lots of native ones per system is also helpful however.
Manual actions should still be in effect for any mode that isn't Experience. They are optional however.
Starting a game varies depending on the NIFE game mode:
Endless/Format -- Hosts can add players manually, or players can sign up via a link. This action can either add them into the game directly or they might wait for Host approval. Players can also sign up directly, which might be useful for Endless but probably not for Format (although there will still be an option).
Experience -- Doesn't require Host interaction since it's creating an instance. On Signup, an instance is created. From here, players can invite additional people to their instance via a link, but only if both the game settings and the initial player allow it. This initial player can also drop other players or turn off their link at any time for any reason.
It's worth pointing out that with Format games, the Host has to first manually create an instance before players can sign up for it -- they can't sign up for the template as that makes no sense. Having them on retainer *also* makes no sense because you'll ideally want active players so the game works.
Rounds -- NIFE classic. Players make manual and automatic actions, but probably have limits. The Host makes things happen after each round ends. Useful for Format and Endless. Certain events can also trigger at each round end. With Experience, the Host isn't directly involved but event triggers can be. Either way, Rounds have some kind of real-time cutoff and if a Host is involved, some kind of downtime is set as well. The Host can set these times up on a schedule or just manually change modes whenever they feel like it (ideally with warning to Players). Players that miss the window can't do anything on that round.
Real-time -- Time passes relative to real world time, possibly with different time systems, months, seasons, etc. If it isn't Experience, the Host can alter the clock at their discretion or freeze it, etc.
Turn-based - Similar to the above, but Time only passes when players do things. Requires either Turn Sequencing or the Experience format. Can be applied to other formats if the Host agrees to it, with a big red note about getting all players around at the same time so things aren't bad from a UX perspective.
Turn Sequencing -- an optional system that makes players only able to do things on their turn. It's definitely in use for most of the combat systems, but it can be general purpose as well. Players can have multiple turns, be slower, etc with plugins. Additionally there should be a time limit on turns, which can I guess vary depending on what's happening exactly (like combat you'll want minutes). Pouch social interaction should help a lot here, and maybe voice chat if I can swing it somehow.
Owners have full control over their Format or Experience Template. There can only be one Owner but they can allow other gtx0 users to become Architects and assist them in whatever ways the Owner allows -- at max permissions they can do anything other than demote the Owner or transfer ownership.
Hosts are the runners of a game instance. With Experience, there is no Host since the game runs itself. With Endless, Hosts are synonymous with Owners. With Format, they're locked to a specific game instance. Owners can alter the functionality that Hosts get downstream to keep their game format balanced.
By default with Format, the Owner also becomes the Host. But if it's a popular Format (or they want to play themselves) they can appoint someone else. There's some additional options here about Format which I'll cover later.
Subhosts are basically just additional Hosts that a Host can allow to work on the instance with them. It's again a permissions thing and works identically to owners/architects.
Demigods are special characters that Hosts can create to interact with their world. Demigods are like characters with Host tools very handy so Hosts can debug more easily. Note that with Experience or Format, a game has to first be instanced. Interacting with the template doesn't make sense as it would be permanent.
Demigods can actually be used in a live game as well -- sometimes the tools make more sense in this setup.
Ghosts are players that are no longer alive but can still see things and watch the game unfold. These can have varying properties depending on the plugins used -- limited or unlimited movement, teleportation, the ability to look at character inventories, etc. They can also just purely haunt the room they died in. It's whatever that particular game needs.
Death Systems
On that note, Death can do various things, depending on what the game needs:
They can just kick a player out of the game altogether. Sometimes this might be the sanest option.
They can see the room they died in and their items/etc but can't do any actions.
They can turn into ghosts of some kind.
Additionally, there are different configurations for what happens with a dead player character:
They can be deleted.
They can drop into Limbo. The character still exists so can still be revived, but nothing else can interact with them.
They can continue to exist as a corpse in the room where they died. This allows them to be interacted with in various ways. The Stealing action should be replaced with a Looting action, and Equipment should be free to Loot as well.
If they're deleted or go to Limbo, there's options for what happens to their items. Items counts equipment as well.
They're deleted. Particularly nasty if the character can be revived later. This can be chanced.
They're left on the corpse. Good for looting potential.
They're dropped. Prevents the need for an explicit Looting action, and also works well if the character is deleted or moved to limbo.
Room Destruction
Rooms can also sort of "die" in various ways:
They can just be deleted.
They can move to the Limbo metaroom. You can't enter anything in the Limbo metaroom except as a demigod or possibly a ghost. Limbo Rooms can be restored later at least.
You can continue to interact with stuff in them but the room entity is dead so you can't do anything with the room directly. Dead rooms are also a useful conditional for, for example, space games where you can't breathe in space.
You would then figure out what happens with room relationships:
Burn -- those relationships just don't work at all anymore
Connect -- you can go to any room relationship from any other room. This can be a separate action or count as the normal movement (maybe with an arrow -->).
Pair -- Relationships get paired together. This can be random or you can set up different rules with different plugins. The Grid variant of this makes the most sense. Either way, this counts as a single movement.
What happens to entities in the room is then determined:
They can be deleted. Optimally you'd want to handle Characters separately though.
They can stay in the room if it's put into Limbo or becomes dead.
They can move to an adjacent room -- one can be assigned as an egress or otherwise it's random. Maybe weights with plugins.
Characters you'll probably want to handle differently. They'll still do one of the above but:
They can take damage.
They can die. If there's a ghost system they either have to be moved out of the room so they ghost there, or the room has to be dead, or ghosts have to be able to move through Limbo.
Additional events can be assigned to entities in the room on room death events (or the general one) as well.
To get around some of the headaches for new hosts, once they pick a game format they can also pick an Archetype for it.
An Archetype drastically simplifies UX because it uses a select set of engines, plugins and options. Archetypes can also be created by Owners, though they would then have to go through some kind of approval process to be in the list (though Owners will at least have access to their own or be able to share them easily)?
Before I go any further it's worth expanding on what exactly I mean by the words "engine" and "plugin" in NIFE v6.
Engines are a broad set of fixtures, equivalent to Plugins in older versions of NIFE. The Hosting CP is getting a huge revamp though so they'll generally have their own panels for better UX.
Engines can be mutually exclusive (time systems for example). They're also quite modular -- I plan to add more over time.
The format of the Hosting CP is changing so that it's a collection of Engines rather than a collection of Panels. You should be able to have direct access to all Rooms if you want, but it'll quit being this clusterfuck thing where you see things that are technically characters clogging up the panels. Engines handle their own thing, and separate engines will allow more fine-grained control.
Another perk is that this groups panels together and also allows for widgets that show things at a glance. This whole thing greatly improves NIFE as a whole. Favorited panels can still be cloned out of their Engines though for quick access, maybe as part of a choiced Overview Engine.
Plugins, meanwhile, turn various complex features on or off. Plugins are a tradeoff between functionality and UX. If you want complex recursive events you're sacrificing ease of use on the events panel, but you do get more functionality.
Since the Hosting panel is tied to Engines (and an Overview Engine), then plugins are specific to each Engine. Somewhere on the Engine you'll be able to specify which plugins you want.
Engines can be turned on or off or switched out at your leisure -- however anything that's attached to them will either need to be deleted, changed or inactivated, for example weather events tied to rounds will need to be removed or changed if you're switching to real-time. A simpler option is just to deactivate them -- they won't be in play (or visible) but if you switch engines back, they'll reappear. Deactivation is the default.
Overall, this kind of thing should simplify *the hell* out of Hosting. They're all still using the same database but there's more layers of abstraction. It also potentially allows for open source engines as well.
