Spice up the game some with ?

[Marbing]

8 minutes ago, Arctique said:

 

My guess, to be taken with a grain of salt because it is just a guess based on limited knowledge of the game's code, is that it would be a pretty big undertaking because:

A) As far as I know, the raw custom enemy group files used by AE are only used by AE, so it wouldn't likely be as easy as plucking a custom mob from AE and just adding it to an enemy group spawn list for radio missions. Either they'd need to have some way to convert a custom AE mob into something the game will recognise as a regular enemy group, or rework how radio missions work so that they can create some sort of framework with which they can just stick AE mob files into them, or recreate those custom mobs entirely from scratch as a new group entirely just based on what was made in AE.

B) There is the question of how they'd have to decide which custom mobs make the cut for showing up in radio missions. Like I mentioned above, developer time would need to inevitably be spent not just integrating a new enemy group into the list of which ones can show up for radio missions, but also thoroughly testing any potential groups to make sure they'd be well balanced against the existing vanilla enemy groups. They'd need to be see how they function against different sized teams and solo players, different ATs and powersets, unslotted builds vs. SO slotted builds vs. fully IO'd, builds with and without Incarnates unlocked, etc. Imagine if you were running radios solo on a SO-slotted Scrapper and get a custom mob, only to find they absolutely curb stomp you because they were only tested for 10 minutes using a fully IO'd Incarnate slotted Brute. Testing and balancing would likely take far more time than the actual coding to add the groups.

C) Which enemies appear in radio missions also varies depending on the zone and level ranges remember, so would these custom made enemy groups just appear at all level ranges in every zone? Or would the devs have to spend time considering where specifically each new mob should appear and within what range of levels? Which will require more testing to make sure that an enemy group that's perfectly fine as level 50 mobs isn't going to be overpowered if fought at level 20 instead.

D) Any new feature or update is inevitably going to have its bugs, so that's more development hours to account for as well. You accepted a radio mission with a custom enemy group, only to find that group wasn't added in properly and didn't actually spawn when you loaded into the mission map? Well that's going to be more time the dev team's going to have to take away from other tasks to now figure out what triggers that bug and how they can fix it.

 

How much they'd be willing to invest the hours into such a feature is something only the dev team themselves can answer, maybe they'll see it as a worthwhile enough addition that it is worth putting the work and the hours in... But game development can be a very lengthy and complex process, especially when your developers are mostly volunteers and hobbyists that have to work with somebody else's decades old spaghetti code.

Just as you said "grain of salt" that also applies to me! 🤣 But I will do my best to address your list with some possible solutions:

A) I know the custom enemy group files are only used in AE, HOWEVER, if you notice in AE you also have the standard enemy groups in there. So if it can go one way it stands to reason it should be possible to go the other. Also, the custom enemies created by players don't behave in any special way that is different from a standard enemy group. They are still bound by the same rules. The only difference is the powers and costumes are chosen for them by the player. If that single difference is enough to make them not portable over to regular PvE content then recreating them would need to be the route you go and recreating an enemy group on source material can't be that difficult or time consuming. You aren't really creating anything new, you are just recreating what's already there with game mechanics, powers, and costume pieces that already exist. Again, grain of salt, because I don't know if that is entirely true, but my guess is that this part of it wouldn't necessarily be overly complicated or time consuming. Didn't they already sort of do this when they created the new "Freakish Lab of Dr. Vahzilok"? I believe there were two entirely new enemy groups added and balanced around lvl 30-39. I could be mistaken.

B) I agree that the time needed to test and balance this cant be understated. Once you have either ported or recreated said custom enemy group (from above) there would need to be some LENGTHY testing of that enemy group. That can be done on the test server by the players during the alpha/beta phases of the patch that would add them. Just make those enemy groups the only ones that spawn on say radio missions (for example, and again ONLY on the TEST server) and have the players hammer them over and over with various build types (SO, sets, Incarnates, etc). You gather the feedback from the players. This would be handled much in the same way as new powersets are tested or how those two new story arcs were tested with new enemy groups and such. 

C) The simple solution to this is to see how the enemies were created in AE. You can stagger the level groupings of your custom enemy group, or even limit them to say level 20. If that enemy group was limited in that way by the creator of the enemy group then balance should be set around that level, and I would say take the highest of that level range and balance it around that. For example if someone creates a custom enemy group that is lvl 20-40 then when that group is ported over (or recreated) to PvE it should be balanced around the lvl 40 range and only appear in lvl 40ish zone radio missions (like Founder's Falls).

D) Bugs are inevitable with any and all new content added and as such makes this kind of a moot point. If it's an expected that effects everything then we can safely call this a break even with any other alternative new content that anyone would suggest. 

And you are right, it all comes down to whether or not the Dev's view the time spent addressing this is worth the return on investment. Is the juice worth the squeeze? That's what its all about.