Jump to content

fingerscrossed

Members
  • Content Count

    195
  • Joined

  • Last visited

About fingerscrossed

  • Rank
    Member
  • Birthday 05/17/1985

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Mentioned in the private message, but you've got my permission. Cheers.
  2. Sadly, I haven't had any time in the past week to work on this. A lot going on atm. Hoping to plug away on the code a bit more this weekend, but will depend on whether or not I have time between some other engagements.
  3. The first thing you bring up is something that is, in my opinion, pretty interesting to discuss, so I'll write about it a bit below. Actions vs Actors I actually currently approach some of this from the opposite direction. At the start of a NPCs turn, it runs a basic check to gather some statistics to see what is a "doable" action. So, for example, it reports the number allies/enemies, number of them that are incapacitated, naked, bound, having sex, etc. That kind of baselines what actions can be taken(For Example, The mod assumes that if you are trying to sex enemies, you have to go Naked -> Bound -> Sex (Currently, might change in the future). Since it's a progression, you can check to see if there's any Naked actors who aren't bound to see if there's anyone to bind. Similarly, a check is run to compare the number of Female Enemies to the number of Naked enemies to see if there is an enemy you can strip). There's a couple of priority checks that get run at this stage. Once an action is selected, it goes to target selection. From here, it runs through finding who all of the valid targets are, if there are any priority targets, and then selects a random viable target. Running Actions before choosing targets and vice versa comes to a design choice of whether you are more interested in controlling the occurrence of certain actions or controlling the occurrence of particular actors being targeted. We can look at it from two simple examples, using random probabilities with no advanced weighting (which I can get into below): Situation 1: The enemy has 4 Female Actors and 1 Male Actor Selecting Action First: We have our "attack" weighting at 3, and our strip weighting at 7, since we're really interested in seeing some titties (ignoring all other actions). We roll actions, and 70% of the time we will choose to strip one of the female actors, the other 30% of the time we will choose to attack one of the actors. 70% to Strip 30% to Attack Selecting Actor First: We first select what actor we are targeting, so there is an 80% it's female and a 20% chance it's male. If it's male, we will always attack it since we can't strip it. If it's female, there's a 70% chance we strip them and a 30% chance we attack. 56% to Strip 44% to Attack Situation 2: There is 1 Female Actor and 4 Male Actors Using the same numbers from above, we get: Selecting Action First: 70% chance to Strip 30% to Attack Selecting Actor First: 14% Chance to Strip 86% Chance to Attack Both methods have merit, but I think that selecting the action first would work better for this situation. This also isn't accounting for any of the potentially more advanced scaling/weighting you could do (i.e. weighting the option to bind enemies higher the more enemies you have that could be bound). Perks So, I think I didn't actually explain the issue with perks too well in my previous post. Storing the perks, what they are, and who has them isn't a huge deal overall. The issue comes into how those perks interact with the main controller. I'll give an example here of where the issue creeps in: Originally, I was thinking I would have a class that gets a perk that lets them act almost normally while fully bound (i.e. can attack, or cast spells, etc). As an idea, this is good. With the current implementation, however, it becomes an issue of how to include this in the code. Say you have 6 perk slots, and it could be any of the 6. You'd also need to have some way of knowing that that, specifically, is what that perk does in the AI controller. Being bound is a separate AI loop from acting normally, so you'd need to have an exception in the "being bound" loop to check for "See if the actor has Perks 1-6, then see if any of those perks enable them to act normally while bound". For a class specific script, this would be very simple, because we would know what the perk is and is doing and could hard code it in. But, for the generalized script, it starts getting messy. Even for simple things, say a Perk that would decrease the overall damage you take, it would need to somehow be incorporated into the script with properties you could toggle for each of the potential 6 perk slots it could go in. Extrapolating out, you'd need a toggle for essentially every perk slot for every possible condition/scaling item it could effect, giving you essentially a number of properties equal to (#Perk Slots)*(#Possible Effects). And even then, for the things where the perks would be more interesting/useful (the things like the above, where it modifies your classes game play) that possible interaction would need to be hardcoded into the script in a way that it could be taken advantage of. Writing this out, however, a thought has crossed my mind on how I might be able to approach this. Rather than, say, each class getting some arrangement of 6 perks, make it so that each class can have a set number of a certain type of perk. For example, you could have two "offensive" perks that increase/modify/whatever your damage, and two "defensive" perks that either modify evasion, or damage reduction, or struggle, etc. Similarly, a "start of battle" perk that could be for things like "At the start of battle, a higher level assassin starts in stealth" or "A high level conjurer starts with a pet summoned" sort of thing. By limiting where each perk could be used, it would greatly cut down on the number and places that a perk would need to be checked for, so less processing, and decrease the amount of properties required for each perk (since each perk wouldn't need all of the properties). I'll have to give it some more thought, but this might actually be a pretty good solution. Alternatively, Perks may just not really need to be a thing, I'm not entirely certain yet, but I'll give it some more thought. On Feedback Also, I appreciate the feedback. For a lot of things, even if I don't end up using something recommended, it's usually good to get additional opinions and new thoughts. For example, until I read through and started responding to your comment, I hadn't considered the above on perks and how I might be able to simplify implementation. Feedback can have a lot of good impacts even outside of the direct topic. It's helpful also just having people to engage and discuss with, especially since the mod is so heavily scripted and trying to get everything laid out is a pretty extensive task.
  4. First real update in a while In Progress Work has begun on making the generic class controller script I mentioned before. I'm working towards making it generic enough, but with enough conditionals and weighting you can change, that any class could run off of it. This does mean, though, that certain things may not be doable. Here's a breakdown of how it's shaping up: Each class can have: Up to 5 attacks Up to 3 other Special Abilities Up to 3 Class Specific Buffs Up to 6 Perks An attack that strips An Attack that Binds (Potentially) An Ability that Places Furniture (Potentially) An Ability to put an actor in Furniture An Attack that starts sex Attacks, Special Abilities, and Perks will have a level tied to them that they are "unlocked" at for that class. Class specific buffs can effect ONLY the class. This would be something like stealth. There will be a set of general effects that can be put on allies/enemies, but these are specific class ability buffs that might have an impact on behavior or special effects. The AI runs through to check what you can, or can't, do and then starts generating your probability matrix for what an actor is going to do depending on the situation. Perks Vs Buffs The difference between perks and buffs is perks are always active and buffs are temporary. As an example, Stealth would be a buff, but "Dagger Mastery" would be a perk. The idea behind this being primarily to give classes special passive bonuses through perks. However, this has an issue: Due to the nature of how the mod is looking to be set up, the things that a perk could do would have to be somewhat limited since they'd need to one of a set of predefined options. Also, even being limited, it would result in a lot of properties (and there are already going to be a lot of properties). Because of this, perks may end up getting removed from design. It'll probably depend on whether or not I can find a good way of doing them. They worked a lot better when there was a class specific script, so that you could easily modify depending on what the perks did. Weights So, how does the script iterate options. Well, it does it through weights, both base and personality bonuses. So, how does that work? Let's look at a very simple example. An action will have a base weight that can be either used at its base value in the script or set in properties. For a female character who is currently getting Sexed, she has three options: 1) She can struggle to try and break free 2) She can Advance the stage, trying to end it sooner 3) She can pass, letting her aggressors continue having their way with her unabated For base chances (without any modification) these are 7, 2, and 1 respectively, meaning that 70% of the time she will try and struggle out. If you are adding a class, you can modify these values for the class, changing the base behavior. In addition, every weight can have up to 3 personalities attached to it. Each of these three personalities would then be assigned a weight. Let's stick with the original base chance of 7 for struggle. Now, let's say that you want to make sure that if your girl is Resistive, she's going to try and struggle more. So you set the 1st personality to Resistive and set the Weight to 10, to really up the odds there. Then you decide that, well, if that's the case the opposite should be true, so if she's submissive she should be unlikely to resist. So, you set the second personalty as submissive and set the weight to -5 to really tone down the odds on resisting. Your happy with this, so you leave the third personality blank and it's weight at 0. And that's pretty much it. It's less for the sex part of things in a lot of ways and more for the regular attacks. Since the script doesn't really know what any given attack does, it doesn't know what personalities would be more likely to make that kind of attack. Alternatively, you can make the class not care about personalities by just not including them. Battle Field Smartness This is something that is significantly harder in a generalized script. Determining what parts of the battlefield the actor cares about and how they care for a generalized script is going to likely be pretty non-existent. At best, it might be possible to make a few general battlefield checks, but even if we make the checks knowing whether or not to apply them and how to apply them becomes tricky, since you would essentially have to have a check for each attack to see if it A) Cares about a battlefield condition and B) The state of that condition. This runs into a similar issue as the perks where it becomes very limited by the generalized form. How smart do they NEED to be? At the end of the day, some of the above comes back to the idea of how smart enemies actually need to be. It's an RPG, not a game of chess and so maybe a lot of things aren't as necessary as really the solution just needs to be "good enough". In some ways, it might even be better, since a less smart AI that relies more on chance to do things is probably more likely to produce varied battle results. The better the AI, the more likely it would be to do the same things every time, which is probably less interesting. Next Up Continuing work on the generalized Control Script. Once the Generalized control script is in place, I'll create the first few classes and start running some tests to see how it works. Hopefully well. This will probably take a little while. Feedback Should the simplest/simpler paths forward be pursued so that an earlier release is more likely, or should extra effort be expended to try and make things as robust and inclusive as possible? Tying into this, for something like Perks where it would require working into the back end how to deal with it, if they missed the initial release, I'd be pretty unlikely to want to go back later and make large changes to get them included, so it has a lot of "now or never" feeling.
  5. Yeah, unless Creation Kit has some functionality there that I'm missing (Which is possible, but I did look a bit!) it does make certain things a bit more complicated. You caught me right between closing the poll and making a post about switching what the poll was about, nice timing! And that's pretty much exactly what the poll is on. The poll itself is, of course, likely to be swayed/subjective because of where I'm hosting it, but I'm curious to get some feedback and see if there is community interest in a non-H version. If there's a good amount of interest, it may be worth looking into it (assuming my method for doing it would work as well as I think), but there does start becoming additional design considerations. There's definitely some consideration for "An MCM option to toggle it off is enough, even if you need the dependencies", but it would limit some potential distribution/user base. If I was going to do that, I'd probably host the base version on Nexus and the Adult version on LL. But, at the end of the day, it comes down to whether or not the extra effort is actually worth it.
  6. Another brief update Poll Results from the First Poll Everyone either voted to pull as much as possible, or to just pull simple forms from the base game. It was fairly close at the end of voting, with pulling as much as possible pulling ahead slightly. I'm planning to move forward with this in mind, trying to see what all can be reliably/easily pulled from the base game to make a good 1-1, but not focusing too heavily on trying to map or use base game assets. Second Poll Second poll is up, and now is the time to throw in your opinions: Should the mod have a base implementation that includes no H/Adult content/action? I've realized that, after giving it some consideration, it may be simpler to do than I originally thought. What would likely happen is: 1) There would be a basic "TurnBasedCombat" mod, with scripts and functionality for simply turning Skyrim combat into your more standard RPG combat. 2) There would be a second mod (Available on LL) that would update the scripts from the above mod to include Adult functionality. One of the goals would be to design the Adult versions so that they would be compatible with Non-H versions. As an example, this would mean that someone could create a class for the Non-H version, and it would work in the H-version, just potentially be unable to perform (or receive) and H-attacks. Classes wouldn't, however, be backwards compatible (Classes made with Adult version being usable in Non-adult). Since I've thought of what seems like a decent way of doing it, now I'm curious to see what the community thinks. Issues: There would be two versions of scripts, so version control could get messy. It would definitely extend development time. I'd have to redo some work I've already done (though some of that work may need to be redone anyways).
  7. I agree with a lot of what you said, and I've looked into a lot of those properties. I haven't had any time to work on this (life has been an absolute bitch the past few weeks), but I'm looking to try and put in a bit of time this weekend. To address a few specific things: In an ideal world, everything would carry over, but it's sadly just not quite the way Bethesda has certain things outlined and set up. Some information is harder to pull, and the exponential growth of choice makes certain things less ideal. I'm more cemented now that I've looked into it into using a class system, if for nothing else than simplifying AI and choices. I'm sure there will be some people who will get annoyed because "I'm the dragonborn, I've maxed all my skills, I can do anything!" but that starts getting into something that is .... kind of a mess. Lots of menus, etc. Vanilla equipment implementation definitely seems like a good way to go and what I'm looking at. The biggest potential problem is damage scaling and "lol uber weapons" vs magic damage scaling (in terms of balance) but it's something solvable. I didn't think of using GetSpeed or GetStagger, but that's actually a good call. GetSpeed could, for example, modify how I was calculating multistrike chance and certain abilities with the chance to stun could use GetStagger. Equipment and Breaking Equipment One of the other things I ran into was changing/modifying some scripts and how things were done. As an example of this, for some of my own mods, I had spells/abilities that would, essentially, wear down (and eventually destroy) armor as it was being damaged. However, for a mod like this, if equipment was being damaged it would need to be able to be repaired. There are already some mods that have this type of functionality, but I'd rather not have to integrate and make any of them a master of this mod, so I've been looking for a simple solution. My current idea is that, when an equipment becomes "broken" it's removed from the actors inventory and placed inside of a specific chest. You would be able to talk to like Blacksmiths or similar merchant NPCs to get an option to repair all of the broken equipment for some percentage of the value of the equipment. It, of course, has some issues (inability to easily choose what to repair, how to handle the PC wanting to repair the equipment themselves, etc.) but for kind of a simple system I think it would work. Scripting Classes Part of the issue I've run into at the moment is I was trying to kind of "future-proof" the mod. I'm looking to run each classes AI on it's own script to reduce the processing burden, simplify processing, etc. Ideally, I originally wanted to do this by having a separate quest and function for each class, with an array of functions that could be called on. As an example, you'd have something like: ClassControllers[0] = AssassinClassController And so be able to call them by their index numbers, and still have separate controllers for each. The issue I've run into is that I can't find a way of doing this, I could make an array of a single script, with each one tied to a different quest, but not an array of different scripts (which makes some sense with the way that Python operates). Now, this has, of course, got me thinking if I can't still make it work. And I think I may, but the implementation will be a bit more difficult. The end result would be creating a single script, say TBCClassController. Inside the script are a set of properties, decisions, and weights that cover various actions. How it would work is that each class would still have it's own quest. So, using the Assassin class as an example, you would have the TBCClassController script on the TBCAssassinQuest quest. You would then add any needed information for the class (Scenes for performing the various attacks, etc), and then go into the properties and set them depending on how you want the class to work. Because of this, there would be limits to the number of actions available to each class (which is somewhat intended), but I think it could still end up making it relatively easy for someone to add a class to the system. There would likely be a large amount of properties that would need to be filled. Some simple examples being: HPScalingFactor (An Integer) ClassName (A String) AttackType1 (A String) AttackScene1 (A Scene) etc. And some more complex factors such as: UseAttackCondition1 (A bool) AttackCondition1 (A spell/effect the actor needs to have to execute) Attack1TargetAllies (A bool, where for true it targets allies and false enemies) And so on. It would limit some complexity on what you could do with the various classes because you'd need to be somewhat formulaic for simplicity, but it would likely still work well enough. It would be easier if there were a way to create a proper index of disparate functions, but I haven't seen or thought of any good way of doing it. I may also split the Class Controllers into broad categories (Physical Classes, Magic Classes, Sex-based Classes, Creature Classes) with separate controllers so that the controllers themselves could reflect that a bit better, so that's also something to consider. A Non-H Implementation The other thing I've been thinking about is whether or not I want to include/create a Non-H implementation for the mod. It was always the idea that there would be a toggle for it, but I've been wondering/thinking whether or not it's worth to make a version without Sexlab/Zaz dependencies, how much extra work it would be, and if it would be worth the extra work. I'm currently leaning towards "probably not worth the extra work" but try to decide before I get too deep into class development, because how I decide on that will probably impact how I implement the classes.
  8. Today's Update: Little actually got done/changed in the mod. Instead, today I've been focusing on the class system and class design. This is both for trying to figure out exactly how classes should operate, and what additional subsystems I will need for the classes to operate. I'm still on very much of a first draft, but the classes and how they work are starting to take a bit of shape in my notes. It is looking like it's going to be a fairly major overhaul of what I already have, but it looks like it will be better. There's some scripting challenges, though, from my ideal implementation that I have yet to figure out. As things get a bit more concrete, I might look to make a longer post (maybe this weekend) with some more info on classes and how they work.
  9. This question is for anyone who has some advanced knowledge of scripting in Skyirm. It's in relation to the Turn Based Combat mod I am working on (check development thread in Sexlab Framework if interested). Here is the crux of the situation: I am designing classes for use in turn based combat. Each class is going to have access to some of it's own abilities and I'm looking into splitting each classes AI/Turn controller into its own script instead of having one larger script run through all possible actions to see if the actor could take them. I would also like to get this set up in a way that I could create some kind of functionality for users to add their own classes to the mod. How I was thinking I'd like to this would be to have a script that would have some naming convention like: TurnBasedCombat[[Class]]Controller That contains all of the basic functions and an outline of how to design a class that modders could use. Each of these controllers would have their own quest that contains the Scenes that correspond to a character using an ability. The Controller scripts would be set up from a template that has all of the appropriate function names so that they are the same across all of the scripts. The idea of what I'd like to do would be have something like: Array of Classes: ClassArray Array of Scripts: ScriptArray Find index of ActorClass in ClassArray. run ScripArray[Index].Function Then, create a function so that additional classes added by mods could be appended to the arrays. My issue: I don't know of a way to make an array of Scripts, essentially. Something that would be like: TurnBasedCombatAlchemistController -- Tied to the Alchemist Quest TurnBasedCombatAssassinController -- Tied to the assassin quest and so on. If you have an idea of how to do this, or how to do something that would achieve the same effect, please let me know.
  10. Quick update: Poll: See the poll added to provide some feedback for mod direction. I am currently starting to look into working on and developing the class system, and I am working on determining how much I should try and include the base game stats in the mod. This ties into things like looking at a characters equipped weapon, searching for in game perks, maybe trying to take into account their training in various skills (1 hand, destruction, etc). There are currently 3 options: 1) As much of this as reasonably possible should be used: Skills should be pulled and factored in, traits should have some kind of similar effect, and so forth. This is the option that would have the non-turn based combat stats affecting this mod the most, but it would also be the most complicated both from a modding perspective and from a user interaction perspective. 2) Simple or straightforward things should transfer: This is essentially things like weapons, armor values, etc (but very likely not enchantments due to the great complication that would have on implementation). This is kind of a middle ground of still being able to improve your character for TBC outside of leveling up without having to likely guess at how something is going to affect the end result. 3) Keep everything separate: Add tiered weapons/armor/etc for the mod. Maybe specific TBC weapons that you can get upgraded through some in mod means rather than try and use weapons from the base game. My feelings are a bit back and forth. Option #1 would be the most work, and I don't think I like it as much. It seems like it would quickly get messy and potentially not feel as good/balanced. Option #3 is interesting and would likely be significantly easier to balance since everything would be "in mod", but that would also mean needing to actually add weapons/items to the mod for each class to balance around. Additionally ways of improving those items so that you would be able to feel your own improvement. I'm leaning mostly towards option #2, because it reduces the necessary game information to try and pull in from Option #1 and reduces the workload from Option #3 while still letting you have an affect on your character's ability with items, armors, etc. But, I'm still working on some of the design aspects, so I wanted to see what the communities opinions were.
  11. Things have been really busy for me lately, so I haven't a had to work on this much. But, here's a small update: Added: - Some initial spells, spell casting options And that's pretty much it for current updates. The spells that are in cast and show the animations for casting but don't deal damage/start combat, so making pretty good progress. I'm looking to get the spells set out and sorted, and then I think I am going to start working on the class system. I have an idea how I am going to implement this.
  12. Today's update: Relatively minor, didn't have much time today. Began working on spell casting implementation, making spells for use in the mod. Fixed a few more things to help with the ability for making zones dynamic. I think my plan is to get the basics of spell casting implemented, then start working on classes.
  13. Today's update: Changed: - Different actions now have their own separate base success chances (That are set up in a way so they can be configured/changed in game) - Positioning, Quest fill, etc. This was a really large change, so see the section below Added: - New Buff Effect: Stealthed (Currently provides +40% to hit, -20% to be hit, and applies sneak attack damage on next attack) - Some gear sets that I'd at least partially previously made that I intend to use (see gear section) Quest Fill and Placement Change: I took a good bit of time today to make some changes and move things around in order to make things more "radiant". In terms of player experience, this won't really mean much, but in terms of modding, current and future it has a big implication. The main change I made is adding several quest Alias that fill using conditions at the start of combat/quest start with minimal inputs needed. If you're wondering what this means in laymens terms, constructing a new battle zone/area should be as simple as: 1) Create a new location 2) Copy a set of core items (position markers) from a test cell to your new location 3) Copy/Add whatever furniture/bondage gear you are looking to add. 4) Decorate your location And, with that location selected in the quest, it should run as a battle zone. I'll need to set up some way to register battlezones with the mod, but I hope that shouldn't be too difficult, and it'll let anyone in the future be able to design a new area for aesthetics, or maybe with their favorite pieces of bondage furniture. This is one of those changes I'm glad to have gotten done, but it took some time and was really tedious. Position Changes: Instead of each side being 5x3 (Actors X rank) each side is now 4x2 and actors can get slotted and move around to open slots. I'm looking into, in the future, providing some kind importance to this, where rank affects hit, who you can attack, etc. With the upgrade to the way I was handling positioning, movement, etc, above I wanted to go ahead and get this upgrade/change in place. Gear: These aren't necessarily complete, but were something I had made previously for my own mod/use. I'm planning to include them in the TBC mod for use in certain situations. There are 3 sets I'll show an initial version of today (note that these are re-textured/re-skinned from ZaZ): Magic: Have you ever thought to yourself: I can conjure an axe. I can conjure a bow. I can conjure a daedric lord. Why can't I conjure up some restraints for this pesky slave? Well, maybe you haven't, but I have. Frost/Icy: Need someone to just chill out for a bit? Do you want to be cool or something? ... Ok, I'll stop with the puns. Spider: Have you ever wondered what would make spiders worse? Depending on your interpretation of worse, web based bondage could be an answer. I'm still on the fence. The retextures still need some work (and I'll need to figure out at some point how to properly put them in Body Slide if I want to distribute them) but I thought people might appreciate seeing it. I'm looking into a fire retextured set as well. CTD: I'm still getting a really odd Crash to Desktop. The crash occurs when hitting escape or opening menu. It doesn't start at the start of combat, and I haven't been able to trace it back to any set of actions that start it, and it doesn't seem to just be time based either. It's kind of a major bug, so it needs to be addressed, but I really have no idea what's causing it, or if it's got something to do with the rest of my install being unstable.
  14. Ahh, okay. Yes, that makes sense. I suppose that comes from some being too much in the reeds. I agree, though, that if the entire team has conditions that, essentially: - Make them unable to take action - Make them unable to defend themselves (i.e. all actions against them succeed) That would definitely be a good situation for ending combat. Probably a more restrictive list than just "disabled" but less restrictive than "Incapacitated/Dead". Which could also play well into adding additional/other effects as alternate ways to effectively "down" enemies. Assuming I'm not missing the point again, which I may be.
  15. So, with the way that stun is currently handled, part of my concern with making it a condition for being "down" and counting towards loss is that it would likely impact where you could have the stunned condition (i.e. what generates it). Right now, stunned is simply "skip your next turn", but it doesn't impact your ability to defend yourself. If it also counted as being "down" then it would potentially limit what applies it (for example, any AoE ability with a stun component could be an instant win, rather than just a very advantageous ability). Part of my reasoning for stunned not being a down condition comes with my below thoughts on ways that conditions are split: A condition that permanent until fixed that completely disables/severely restricts your ability to take actions that the actor can't fix themselves - Down (I.e. Incapacitated or maybe something like petrification) A condition that is temporary that completely disables/severely restricts your ability to take actions that the actor can't fix themselves - Not Down (i.e. stun, where it is missing a single turn) A condition that permanent until fixed that completely disables/severely restricts your ability to take actions that the actor has a small chance to fix themselves - Maybe down (i.e. being placed in a pillory or similarly challenging bondage) Maybe the best option would be to include options that stunned actors can count towards party down and be able to set a threshold of "Bound individual counts as down if they're struggle chance is less than X%" (particularly if you have, say, a 0% or less chance to struggle free). It might also be something that just needs more play to figure out and get a feel for, but my initial inclination to leave stun as a non-down condition was to leave "downs" as a stricter condition set so that the player wouldn't potentially have as much variance on random losses. I'll have to give it some more thought. Feedback, particularly feedback early in development, is always useful. When you're in the thick of things it's easy to miss or overlook a lot of things. As I'm working on some of this, I am trying to think some about what functions/functionality other mods tapping into this mod may want to have (so I can perhaps do some design with that in mind), but at the moment I'm mostly focused on getting the mod itself working. I think that, at in the end, what I'm likely to do is a combination of using already existing characters and then creating something similar to classes for the mod. It looks like it would simplify, probably quite significantly, some of the AI by having classes (and therefore, for each class, there are only a limited number of options that they can take). Especially as I add more options and abilities, it would keep quite a bit simpler. This also got me thinking about a way to do levels/leveling that ... may work. I'll have to look into a bit, but I'm thinking there might be a way to attach something to an actor that will track what level they are (I'm thinking of using a Level spell, that has two magic effects: Level, and Experience, and then adjusting and modifying the magnitudes after combat). This could also potentially keep the turn based combat levels/abilities entirely separate from the base game combat. I'm not sure if this would actually work the way I wanted it to, though (If the values would carry and save properly between save/load states, and when actors were loaded/unloaded). What I'm thinking I might look to do is: 1) Finish fleshing out and making various actions 2) Make sure the actions are working in game 3) Design classes based on available actions. For #3, it'd might be something like: Class: Assassin Usable Actions: Attack, Stealth, Sex/Bondage, Assist Ally, Struggle, Flee/Surrender, Pass Perks: Bonus to Stealth (At Level 5), Bonus Sneak Attack Damage (level 10), etc. Special Abilities: Poisoned Attack, Assassinate, Smoke Bomb Where some actions are universal (or mostly universal) such as: Sex/Bondage, Assist Ally, Struggle, Flee/Surrender, and Pass And some base actions are dependent on class (Attack, Cast, Heal, Stealth, Command, etc.) Perks would be passive bonuses. Special Abilities would probably be part of a subset. So, in the above example, it would check to see whether to use Poisoned Attack or Assassinate when attack is rolled instead of just a base attack. I have not only heard of, but have played quite a bit of Darkest Dungeon. I really enjoy the game, and from a modding a standpoint, my biggest complaint for it is just that there is a lot of limited factors on what you can do with the combat system (since there isn't much you can do with the combat animations and pairing them).
×
×
  • Create New...