Jump to content

Darth Futuza

Members
  • Content Count

    1,814
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    USA
  • Interests
    JKG Developer
  • Modding Interests
    Coder
    Texture Artist
    Jack of all Trades
  • Gaming Specialty
    Capture the Flag
  • Operating System
    Windows 10 / Linux Mint

Contact Methods

  • Website
    https://www.jkgalaxies.net/
  • Discord
    https://discord.gg/YuG8Zks

Recent Profile Visitors

2,842 profile views
  1. Oh neat. Nice work, should be interesting.
  2. Just wanted to add that if you need more technical details for any of the menu stuff not covered in the basic tutorial, JKA's menus are basically identical to the one's listed in the Quake III documentation located here.
  3. Sat, Oct 3 UTC 6:30PM(18:30) we will be holding a Community Scrimmage Match for fun. Additional matches will likely be held throughout the day depending on how long the community wants to play for, so if you can't make that time others will likely be playing later that day. If this is your first time trying the mod, go here to download it. Countdown: https://countingdownto.com/?c=3243617
  4. Curious if collaboration/group entries are allowed?
    Haha this is great Ramikad, gives me ideas for infection style game modes. (eg: one player is the virus and spreads by killing other players 'converting' them to their team, last one remaining wins, etc)
  5. Introduction: This topic means to propose the Rumor Gathering system, the developers have discussed this briefly before and I'm bringing it back up. This is for Phase II/Phase III. Q: What is Rumor Gathering? A: It is a system we will put in place to help with two things mainly: 1. Dynamic Quest requirements, helps quests be different every time while also being able to hide certain types of requirements. 2. Workload, we want dynamic quests without too much work. Basically, in summary, it allows certain dynamic NPCs conversation trees to only be explored if enough Rumor has been gathered, instead of specific bits of 'rumor' we just give out generic rumor "points" in different categories, and require a certain amount per category to allow the dialogue option to appear, otherwise the player will not see it until enough rumors have been collected. There are several possible "sources" of rumors: npcs, holocrons, holonet, books, certain quest objects, etc...it might even be possible to let players spread rumors for us! The System Categories There are a total of 4 main categories (I could think of), that we could have rumors for: Skill Rumor Knowledge Faction Rumor Knowledge People Rumor Knowledge Places Rumor Knowledge Each of these contains subcategories of their own. eg: Skill: Force, Weapons, Armor, Miscellaneous Faction: Imperial, Rebel, Local factions, Black Sun, SorruSub, Jedi Exiles, Smugglers, Miscellaneous Groups People: Local Persons, Notable Persons (ie: Emperor Palpatine, Grand Moff Tarkin, Senator Organa, etc...) Places: Tatooine, Dantooine, Taris, Korriban, Miscellaneous Locations (instances, etc) How to acquire Rumor Knowledge Find a "source of rumor" (ie: barkeeper, book, drunkard, terminal, etc...), and then begin using it or conversing with it. Eventually after exploring the correct dialogue choices, or merely by interacting with it it will increase your rumor points (usually in specific categories, but this could be randomized as well). Mostly likely implemented via a luascript/cmd. Rumor Points Rumor Points are a way of keeping track of the total amount of Rumor Gathering the player has done. Rumor Points are added each time you obtain a rumor. They can be found on one's datapad. By looking at the datapad a big list of rumors that the player has uncovered will pull up. Only special rumors will actually be listed here. Most rumors, simply give you rumor "points" and won't actually have a rumor entry in the datapad. These special rumors will be organized by date, by default or category. Often times rumors don't in themselves contain anything, but generic information that the player already knew. The player may sometimes acquire duplicate rumors, but never from the same source. We may wish to also have a large list of generic rumors by subject for all possible rumors, similar to treasure classes which could be assigned to as a list for the game to pick from when a rumor source tries to generate rumors from a certain category. Rumor points can also be negative. -Example of Rumor Point format for a "special" rumor (these are separate from just general rumors, that simply give you points): Rumor: "Heard a rumor that there are no Jedi's left in the galaxy, and the force can no longer be used." Category: Faction Knowledge, Jedi Exiles. Source: NPC Jankins, Tatooine Rumor Points: -2 Jedi Exiles Rumor: "There is a mad hermit with supposed magic powers, near Mos Eisely". Category: Faction Knowledge, Jedi Exiles Rumor Points: +5 Jedi Exiles As you can see rumors can provide positive or negative values of rumor points, so picking up rumors from the wrong sources (consulting Imperials that don't believe in Jedi's, when you are trying to find one), will hurt your overall point score in that subject (however it may be boosted in others, such as your increase in knowledge about Imperials). Players cannot see what the actual point values are for each category, this is a mystery to them. However, they see bars for each section go up and down, but without actual values presented and just a general indicator that a rumor may have made a change to their overall knowledge in that category. Having a full bar in a particular category typically means that the player knows all there is to know about that rumor subject. So let's see a whole example, without "special" rumors. Player A is trying to find more information about the Jedi Exiles faction. First he talks to an Imperial officer asking about an Imperial outpost. The Imperial knows nothing useful about the Jedi Exiles: Imperial: "How can I help you, citizen?" Player A: "How big is the garrison here?" I: "*sigh* "Almost 200 strong, we badly need reinforcements." P: "Why, been attacked?" I: "No...*sigh* smugglers, thieves, slavers, they all slip through we've never been attacked since all the Jedi Rebellion years ago during the end of the Clone Wars. We have nothing to fear. But smugglers are certainly frustrating." P: "Well I wish I could help, but I haven't the time right now. Good luck." This NPC then gives out some rumor points (objects will need some function added to them to incorporate this). What factors into the rumor point distribution: 1. How long the player conversed with the source. (How many total tree nodes we're explored from the total branches)? 2. Random Factor. 3. Limits set on what kind of rumor points the source can give out. 4. Amounts of rumor points already given out to this player from this source, as well as certain special rumors may require special cases. So in this example the Imperial could have given out any rumors pertaining to Local Imperial Knowledge, or give negative points for the Jedi Exile. ie: +1-2 points in Imperial, +3-4 Imperial, +4-5 Imperial, -1 Jedi Exiles, or +1Local Tatooine. You would likely get the +4-5 Imperial if all tree branches of that NPC had been explored. However, the random factor may still make you unlucky and give you something worse (-1 Jedi Exiles). Typically we'll only do this type of rumor point generation on npcs who do not have tree dialog (eg: they say one thing when you interact, but that's it). NPCs with dialogue trees will probably have custom rumor points given when certain dialog trees are explored. How Rumor Points will be Used Certain NPCs may only begin certain dynamic dialogue options, when the persons rumor points in a certain category are a minimal amount. Quest creators can then set certain dialog trees as being locked until the player has enough of certain rumors. Rumors represent the players efforts to essential uncover truth and will go up (or down) as they learn and gather information in the world. For example, our Imperial gives out negative Jedi Exile points because he is under the wrong and false impression that there are no more Jedi left, since Order 66, despite the fact that there are still Jed out there. Hence by denying the Jedi Exiles existence to do so, because the player may or may not be effected by the belief (simulated by a random selection). Merely by consulting a untrustworthy rumor source, the player runs the risk of decreasing his faith and belief that the rumors he has heard about that topic are actually true. Rumor Source Format Most rumors don't get put in the datapad, only special ones the writers actually want to bother writing and attaching to a particular source (quest NPC). The rest of the rumors simply add rumor points to your rumor knowledge or take it away. So again with an example with the Imperial his object file would go something like this (using pseudo json): { //Example Imperial #245 //Location of NPC: Tatooine, Mos Eisely, coord: 2, 5550, 323 "Name": "npc_imp_245_ex", //name of the object using the rumor property "Source": true, //Is this a source of rumors? true/false "Special": true, //Is this a special rumor source? "Multiple": 0, //Can this source give out more than one category rumor point at once? "Timeout": 1440, //How many minutes does it take for this source to- //-time out before it can give out rumor points again? "Categories": //start of category definition section [ { "Type": ["Imperial"], //What type of rumor point category is the first type? "Max": 5, //What is the maximum amount of points to give out? "Min": 1, //Minimum? "Weight": 50 //0-100% How often should this choice be chosen? (50% of the time). }, { "Type": ["Jedi Exile"], "Max": 0, "Min: -1, "Weight": 25 }, { "Type: ["Tatooine"], "Max": 2, "Min: "0, "Weight": 25 } ] } Other Specifications The system would also in addition to previous information, need to track to see if that "rumor" has been given already and if not allow the player to basically spam mine rumors unless it has already been given to the player. For example once Player A has spoken with Imperial_245 he is not going to give the player any more rumor points until after the 1440 minutes are up (24 hours). Some rumor sources never timeout and are only found once. Other NPCs give out multiple vague rumors and have timeouts so the player can collect new rumors from them after coming back latter. Likely these timeouts would be between 8-48 hours, this will prevent the grinding or mass spam "mining of rumors", at least from one rumor source. Some NPCs can even have multiple requirements for dialogue options to appear. ie: More than one category, or total overall rumor points. Others may require special rumors to be found from specific sources (ie: holocrons, instance npcs, etc...) [ b]Further Development Ideas (please respond with your own ideas!)[/b] - allow players to spread their own rumors? ie: if player is part of a certain faction, speaking to that player basically via chat will allow a chance to pick up rumor points covering that faction. Could run into problems if players start advertising they can give out rumor points or something and then stand all day in the city spamming everyone and giving them rumor points. -Every rumor point adds some bit of random Starwars lore in the datapad that slowly gets unlocked? -Allow player to know that rumor knowledge has been acquired. For example a, "rumor" sound effect, or a popup dialogue box similar to the darkside/lightside point boxes in KoToR. We could also in the quest log add a piece of info that says something like, ""Obtained hearsay from npcs so & so, about Jedi Exiles". -Bonus from rumor points in that skill. For example if you have lots of rumor points in Skills: Force, you get increased force points, regeneration of force points, etc..? -Skill that can be learned to increase the rate or amount of rumor points you can receive from npcs. ie: X2 Rumor points, etc... -Allow players to 'share' rumors. So for example Player A can select one player to share a rumor with. Once the rumor is shared it cannot be shared with anyone else, however, Player A can still share other rumors he hasn't already shared with the same, or different players.
    Just finished Fallen Order, this looks great. Nice job.
  6. So we've recently been talking a little bit about NPC design in the Discord, so I thought I'd make a discussion thread about it so we can have a place to keep the ideas around. There should be a couple of things to keep in mind regarding NPC behavior and purposes that I want to talk about first, especially in regards to their goals and purpose in the game. Most of this deals with Phase 2 and later design, so just assume we're talking about that phase here, since NPCs will have little to no use in Phase 1 (as of right now). I'm going to discuss some of my thoughts on the design, but want to hear feedback from other players/developers. NPC Purposes in JKG I think its helpful to review NPCs from a gameplay design aspect. Why are NPCs in JKG? To serve as facilitators of items. Some NPCs produce items and you can trade with them to acquire new items. eg: A shop vendor can sell you a new e-11. To serve as facilitators of skills/abilities. Some NPCs can help players unlock new skills/abilities. eg: An npc craftsman can help a player unlock the craft items skill so the player can then craft items. To serve as distributors of quests/missions. Some NPCs can help players learn about new things and give them things to do, they can also help move the story along. eg: A caravan guard on Tatooine might ask you for help when they get stranded by a Krayt Dragon attack. To serve as obstacles and antagonists, that make quests/missions more challenging and interesting. To serve as helpers or allies, that make quests/missions easier, interesting, or even more challenging. To help fill the void of a server with the semblance of life and add to the game's atmosphere when other player's are not around. Given these primary reasons, it makes sense that we should probably optimize/design NPCs around these goals. Not all NPCs are equal, and its fine to disable certain features with some npcs to optimize. For example, shop vendors probably do not need to serve as obstacles or antagonists so they shouldn't have the overhead of trying to figure out how to kill a player like a stormtrooper might. Some NPCs should probably have scripted actions and not need to do anything other than follow a script. Others should be more dynamic and self determining. All NPCs should have a couple of different universal ways they might interact with a player: +use on an npc will open up a dialog with the npc as long as the npc is not currently hostile to the player, or is not a vendor that the player has interacted with previously. There should probably be a check that goes something like: if(npc.attitude == HOSTILE)//doesn't like player, won't talk to them {return;} if(npc.quest.dialogflag == -1) //dialogflag: -1=talked to, no more interactions, 0=never talked to, 1=dialog available, 2=quest/special interactions, etc. { //do default npc action here, such as a vendor opening his shop return; } //other npc reactions below Otherwise, the npc would open up a dialogue with the player and the player can choose how to respond. All NPCs should have an escape dialogue choice available. This will usually be the last listed and would be something like, "Goodbye" or "[Leave]". This can always be called by pressing "ESC" to close out a dialog with an NPC. NPC dialogs should be designed so that the player can leave the conversation at any moment and pick it up later (in case of a client disconnect or player backing out, whatever). Other dialog choices would be based on the NPC itself. For example when talking to a vendor for the first time, they might introduce themselves and tell you that they can sell you stuff, and one dialog option would be to look at their wares. Most vendors, should probably only do this interaction once with each player, and then set their dialogflag to -1 (meaning that if you talk to them in the future it just skips straight to the shop screen). Quest NPCs would have additional dialog choices available while the quest is available, for example a stormtrooper might give you an option to ask him about how he became a stormtrooper, which would lead into a imperial recruiting quest. Attacking an NPC will probably be a little complex, but here's some basic ideas. First, make sure the npc is actually attackable and if not, don't bother doing anything. For example, you shouldn't be able to kill or harm certain NPCs during certain points in the game. In general though, assuming the npc is a valid target and currently friendly toward the player the following steps should probably happen. In general, while these principles apply to player vs npc scenarios, they might also be applicable in npc vs npc scenarios. Lower the NPCs attitude value toward the player. Reduce it more significantly depending on the amount of damage done or debuffs applied. eg: A stun has far less severe consequences than lighting an npc on fire does. Doing 100 dmg, lowers the attitude far more than 10 dmg does. This attitude value might be increased through other interactions with the npc, such as healing it, talking to it, doing quests for it, belonging to the same faction as it, etc. Any nearby NPCs that have a visual on the player and the attacked NPC should also consider if they like or dislike or are indifferent toward the action the player is taking. For example, Darth Vader would like it if the player kills a rebel npc, but dislike it if the player kills a stormtrooper and be indifferent toward the player killing a jawa. They should then lower or increase their attitude value toward the player. This would be far less significant than the effect of a direct attack. eg: 1 point up/down, instead of 20, etc. If the attitude value remains positive, the NPC should warn the player not to do that verbally/visually, but not do anything yet. eg: similar to the warn jaden sounds If the attitude drops to negative, the NPC will begin treating the player as hostile and any other player's he is currently on a team with. NPCs with a hostile attitude may do different things depending on the who they are. For example, a stormtrooper will probably just begin attacking the player. Not all NPCs of the same class should necessarily behave the same, see below for details. If the player attacked an NPC at somewhere other than neutral/no man's land, they should also be given notoriety points, just as they would with attacking a player. Hostile NPCs: When an npc becomes hostile toward another player it may do several different things depending on its class and personality. For example: A jawa might run away in fear. A quest npc, might fail your current quest/change the requirements. A shopkeeper might refuse to trade with you. Etc. Typically most NPCs will attack the player and their allies. However there are a couple of things to factor in, the NPC will need to consider a couple of things: Does it know where the hostile player/npc is? (Does it a visual within its range?) How long ago did it last have a visual on the target? Does it have a weapon(s) to defend itself with? And does that weapon have range to hit the target? Is it outnumbered? Is it outleveled? What is its personality? NPCs should have the option of having a random personality generated with each spawn, this way every npc is slightly different with how they approach situations to some degree. Developers can script in certain restrictions so some NPCs always react the same way, but for most the default will be just random personality biases. For example while Jawa's might tend to be more on the cowardly end of the spectrum and choosing to flee or find cover when in a hostile situation, occasionally one might have the rare chance of being born with courage and thus fight to defend itself instead of fleeing. We would generate these similar to how treasureclass's work with items, where a set of ranges is specified for each npc class and the values generated for each behavior category being within the range specified (will talk about those categories later). How many of its allies has the target already killed/attacked? After evaluating the above, the hostile NPC will most likely either try to flee or fight the player. Its personality and equipment will help determine its fighting 'style'. For example, if its more cowardly, it might try to snipe the player while ducking down beneath cover if it is a considerable range away from the player. If it is completely outmatched in level, equipment, and not brave, it will probably just try to run away from the player as far as it can get. If it has other allies and feels confident in attacking the player, they might try to work together to flush the player out of hiding, by encircling the player's position for example. NPC Personality Category Ideas, these would probably be variable amounts, eg: -100 to 100, or 0 to 100, depending on the npcs value. The npc file would determine the range generated for each category, or use a default if not specified: <Brave-----Coward> (NPC will fight or flee) <Reckless----Cautious> (NPC will abandon self preservation vs prioritize staying alive) <Prefers Range-----Prefers Melee> (How close to the player with the NPC try to get?) <Prefers Backup----Prefers to Solo> (NPC might only fight if it has a group, or fight regardless of allies). <Friendly Fire----Save Allies> (NPC will kill its allies if it has to vs always prioritizing saving its allies instead of the player) <Curious> (How likely the NPC is to investigate odd things. eg: If its companion dies, does it look for a cause or if it hears something odd, or does it ignore stuff) <Preferred Weapon> (Does the NPC have a preferred weapon, when given a choice. eg: if an npc has a rocket launcher, an e-11 and a grenade which one does it choose if they're all in range?) <Darkside----Lightside> (Which spectrum is the npc on?) <Hates> (Is there anything the NPC hates above everything else? eg: Does it hate Tusken Raiders and will focus a Tusken over a player whenever faced with both?)Most We also need to talk about pathfinding/routing and how that should work, but I figured I'd let Xycaleth weigh in on that first since he's been playing with it the most.
  7. Thanks to everyone for helping us play test this new version. The play tests have concluded, we found a few bugs and appreciate all the feedback everyone has sent us. If you have additional feedback feel free to post it in the Discord or here in this thread. A hotfix for v1.3.22 has been released to deal with the more serious issues encountered, but most of the changes based on your feedback will be implemented in later updates. Thanks again!
  8. One match left! We had some good fun games and even found the cause of the last (hopefully) server stability bug we missed, also got lots of great feedback from new players and old veterans. Its been great so far.
    So this is what happens when you give a Jawa too many steroid injections.
  9. Hello! The beta for v1.3.22 was just released and we need your help testing it. We have three planned test scrimmage matches this coming weekend (times are UTC): Thursday, July 10th at 10:00pm UTC Saturday July 11th at 1:00am UTC Saturday July 11th at 8pm UTC To get the latest preview build, go here (you'll want both map packs as well) . More news about the scrimmage will be upcoming, to stay up to date watch the Discord #announcement channel. You'll most likely want the map packs as well!
  10. I have also now added an OSX binary for you Mac users out there. (Special thanks to Flate for helping me with that). Scratch that it looks like we built it wrong, getting it fixed will be reuploaded once its been fixed.
×
×
  • Create New...