test content
What is the Arc Client?
Install Arc

Bringing Back both the Foundry AND the old exploration system.

I'd like to talk about Bringing Back both the Foundry AND the old exploration system, but not in the way most would think.

There is no way that any of us can honestly say that Foundry and the old exploration system were without problems. Foundry kept breaking, and exploration was a smelly mess, and fixing the Foundry was too hard due to lack of available human resources to stay on top of it, and fixing exploration amounted to just removing buggy maps out of the random rotation. The game is arguably better or worse without these mechanics, depending on who you ask.

Recently, I posted a topic entitled "What would YOU add to STO?" The purpose was to get as many answers to that question in one discussion, rather than dredging up a whole bunch of existing threads, many of which would result in necro-posting if referenced. I felt it was important to consolidate as many responses into a current active thread. The return of the Foundry and the addition of exploration have been recurring elements. So I wanted to address them.

Those who are familiar with my posting history know that I am a strong proponent for exploration, and that I was a strong opponent for the removal of the Foundry, which after exploration was removed became the unofficial alternative.

The biggest problem with the foundry was its design. It relied on a database that was isolated from the core game's database. But there was only one game client. When the core game was updated, both the core database and the client were updated accordingly, but the Foundry database was not. That's why it kept breaking. The more the core game was updated, the more incompatible the Foundry database became with the client, making it a bigger and bigger mess for a team that did not have the extra manpower to spare to fix and maintain. Had STO been designed around the notion of user generated content being a core component, A shared database might have been possible, so everything could have gotten updated accordingly. And that is the answer to Foundry's return. As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.

Nothing done on the Foundry shard would impact Holodeck, Tribble or Redshirt in any way. It would have its own ruleset, and could deliver an entirely interactive storytelling experience that could never be used to game the core system. It would exist to service those interested in the narrative aspect of the STO universe.

Playing on Foundry would be a different experience from the other shards. You won't create a character like normal. The Foundry Author will be required to create a primary protagonist character and his/her ship and that ship's interior map and bridge. When a player on Foundry first starts, the oldest Foundry mission loads and the player experiences it in the role the author created. when the story ends, the layer may react to the author accordingly:

Upvote
Remain Neutral
Downvote

If the player upvotes the author, then the next mission to load will be that author's next mission, if available. The system would always attempt to pull missions from authors the player has upvoted first, then neutral missions, and then downvoted missions. The upvoting or downvoting would only reflect individual players mission load priority and give the author a upvote to downvote ratio for his/her missions. Just because one person may not enjoy a mission does not mean someone else won't, so there should be nothing that impacts priority weighting for anyone other than the voter.

Under a mechanic like this, Foundry would be like experiencing fan fiction in the context of storytelling only.

The old exploration mechanic could be applied by an author to put the player into a random loop, with a potential encounter or plot-centric discovery in the process. Having the travel points being randomized adds a layer of unpredictability to the sequencing of events.

Under this approach, Foundry would be able to run as-is without mandatory updates, and will not need a dedicated coder to monkey with it every time the core game gets updated. And when new elements get added, the Foundry client and database would be updated and should continue to work.

I know that it is unlikely for Foundry to return in any form. This is just an idea of how it COULD return without the issues thst made it so problematic before...

Agree or disagree. No skin off my nose. I'm just an idea guy here.
When it comes to MMOs, I wear prescription glasses. Whether or not they are rose-tinted is beside the point.

Comments

  • somtaawkharsomtaawkhar Member Posts: 8,968 Arc User
    edited July 2020
    A shared database might have been possible, so everything could have gotten updated accordingly. And that is the answer to Foundry's return. As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.
    A shared database solves nothing, and, if anything, would make problems worse for both the devs, and Foundry authors.

    While a shared database would update the models, textures, and scripts, that wouldn't prevent things from breaking. As we saw with the anniversary update, and the updated Krenim and Iconian textures, while the older maps did update a bit for them, this still resulted in massive cases of missing textures, or texture splits, like in the Krenim fleet holding, because the new ones weren't made to the exact same size as the old ones. Even if the Foundry auto updated Foundry missions with the new stuff, it would still result these same sorts of problems.

    This would be even worse when it comes to scripting. If a foundry mission used a script to make a NPC walk somewhere, and use a computer, very often its not just the result the script produces, but the WAY it produces that result that matters. Changing this script, even if it has the same result, could still very easily break the timing and sequencing of Foundry missions if the script is able to put out that result faster, or slower, then before, meaning the NPCs are performing said actions faster or slow then originally intended. This is something I've seen happen in Bethesda game mods several times as far back as Morrowind.

    A shared databse automatically updating these elements as the game gets patched would just create mass havoc unless Foundry authors were given an exceedingly comprehensive detailing of not only everything that changed, and how they made said change was made, so they could go in an redo their mission to account for said changes. And even then, they can't be 100% accurate about it, so things are still going to break in mass regardless.
  • sirsitsalotsirsitsalot Member Posts: 2,338 Arc User
    A shared database might have been possible, so everything could have gotten updated accordingly. And that is the answer to Foundry's return. As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.
    A shared database solves nothing, and, if anything, would make problems worse for both the devs, and Foundry authors.

    While a shared database would update the models, textures, and scripts, that wouldn't prevent things from breaking. As we saw with the anniversary update, and the updated Krenim and Iconian textures, while the older maps did update a bit for them, this still resulted in massive cases of missing textures, or texture splits, like in the Krenim fleet holding, because the new ones weren't made to the exact same size as the old ones. Even if the Foundry auto updated Foundry missions with the new stuff, it would still result these same sorts of problems.

    This would be even worse when it comes to scripting. If a foundry mission used a script to make a NPC walk somewhere, and use a computer, very often its not just the result the script produces, but the WAY it produces that result that matters. Changing this script, even if it has the same result, could still very easily break the timing and sequencing of Foundry missions if the script is able to put out that result faster, or slower, then before, meaning the NPCs are performing said actions faster or slow then originally intended. This is something I've seen happen in Bethesda game mods several times as far back as Morrowind.

    A shared databse automatically updating these elements as the game gets patched would just create mass havoc unless Foundry authors were given an exceedingly comprehensive detailing of not only everything that changed, and how they made said change was made, so they could go in an redo their mission to account for said changes. And even then, they can't be 100% accurate about it, so things are still going to break in mass regardless.

    I will concede that point... However, the way I propose hypothetically bringing Foundry back will eliminate those problems. It would have to stand completely on its own.
    When it comes to MMOs, I wear prescription glasses. Whether or not they are rose-tinted is beside the point.
  • somtaawkharsomtaawkhar Member Posts: 8,968 Arc User
    edited July 2020
    I will concede that point... However, the way I propose hypothetically bringing Foundry back will eliminate those problems. It would have to stand completely on its own.
    Then I am not understanding this line
    As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.
    You talk about a shared database, then mention it being synced to the database while on its own client. If its synced to the database, even if its on its own client, then its still getting all the database updates, which would cause all the breaks I mentioned above. If its not getting the updates, then it wouldn't be synced. I assumed you weren't talking about a character sync since you mentioned mod authors needing make their own playable characters, but if it isn't syncing characters, and isn't syncing content updates, what is it syncing then?

    If it isn't synced to the database, and thus not getting the updates, then the Foundry is stuck in a permanent state of limbo, not getting any of the new assets, scripting, technologies, species, ships, etc. etc. added to the base game after the point of its creation. Adding these things in later in some manual update would necessitate adding in all the new scripting/mode/texture changes as well, resulting in the game problems I mentioned earlier.

    Either way, there is no avoiding the problem of the things in the Foundry breaking whenever Cryptic adds in some new thing, be it in real time, via a constant database sync, or whenever they get around to dumping the new assets into the Foundry via some periodic update.
  • sirsitsalotsirsitsalot Member Posts: 2,338 Arc User
    I will concede that point... However, the way I propose hypothetically bringing Foundry back will eliminate those problems. It would have to stand completely on its own.
    Then I am not understanding this line
    As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.
    You talk about a shared database, then mention it being synced to the database while on its own client. If its synced to the database, even if its on its own client, then its still getting all the database updates, which would cause all the breaks I mentioned above. If its not getting the updates, then it wouldn't be synced. I assumed you weren't talking about a character sync since you mentioned mod authors needing make their own playable characters, but if it isn't syncing characters, and isn't syncing content updates, what is it syncing then?

    If it isn't synced to the database, and thus not getting the updates, then the Foundry is stuck in a permanent state of limbo, not getting any of the new assets, scripting, technologies, species, ships, etc. etc. added to the base game after the point of its creation. Adding these things in later in some manual update would necessitate adding in all the new scripting/mode/texture changes as well, resulting in the game problems I mentioned earlier.

    Either way, there is no avoiding the problem of the things in the Foundry breaking whenever Cryptic adds in some new thing, be it in real time, via a constant database sync, or whenever they get around to dumping the new assets into the Foundry via some periodic update.

    Tribble, Reddhirt and Holodeck all have their own client and their own database. They are maintained independently...

    There are things on Tribble that do not exist on Holodeck. When an update goes live to the actual game, the client and database are uptaded. If Tribble updates, it does not impact Holodeck in the slightest. The reverse is also true.

    Holodeck client synced with Holodeck database and is not impacted when Tribble or Redshirt are updated
    Tribble client synced with Tribble database ad is not impacted when Holodeck or Redshirt are updated.
    Redshirt client synced with Redshirt Databae and is not impacted when Holodeck or Tribble are updated

    So...

    Foundry client synced with foundry database would not be impacted when Holodeck, Tribble or Redshirt are updated.
    When it comes to MMOs, I wear prescription glasses. Whether or not they are rose-tinted is beside the point.
  • nixie50nixie50 Member Posts: 745 Arc User
    the realistic answer is that unless someone is willing to pay the salary of a dedicated dev, it's not happening
    80d.gif
  • sirsitsalotsirsitsalot Member Posts: 2,338 Arc User
    nixie50 wrote: »
    the realistic answer is that unless someone is willing to pay the salary of a dedicated dev, it's not happening

    If deployed to its own shard a Foundry client synced with a Foundry database would not be impacted when any other shard is updated. So once deployed, it could run independently and not have to be fixed every time the main game got updated. Foundry gameplay would have to stand completely on its own with its own client and database.
    When it comes to MMOs, I wear prescription glasses. Whether or not they are rose-tinted is beside the point.
  • rattler2rattler2 Member Posts: 52,984 Community Moderator
    So give the Foundry its own, independent server, inaccessable to Holodeck.

    Also isn't this technically an FCT topic?
    66998372863950ee98cf7da9786e2ea9-db80k0m.png
    I can't take it anymore! Could everyone just chill out for two seconds before something CRAZY happens again?!
    The nut who actually ground out a Delta Pack, Temporal Pack, and Gamma Pack
    The resident forum voice of reason (I HAZ FORUM REP! YAY!)
  • spiritbornspiritborn Member Posts: 3,032 Arc User
    Also the Foundry breaking had nothing to do with the database, Foundry having a separate database meant it took a while for us to get ships, uniforms and so forth. however the Foundry broke as STO code wasn't never meant to support that function and it was a bit of bubblegum patch that made it possible in the first place.

    The Foundry asset Database was pretty much never the issue and it was always the case of the foundry making STO do things it wasn't suppose to be able to do.
  • thegrandnagus1thegrandnagus1 Member Posts: 4,528 Arc User
    And that is the answer to Foundry's return. As a shard of its own, like Redshirt or Tribble. It would have its own client, synced with the database. And if launched in a functional state, could be left alone to run independently of the core game, not breaking when the core game gets updated.

    Anyone who thinks they have come up with an idea for a system that can't break is extremely, extremely, extremely naive.

    Here is how it would actually play out: games break in many unexpected ways. Your proposed system, despite your thinking otherwise, would also break.

    The question is, what happens next? I'll tell you: the people who play mainly for the foundry would DEMAND it be fixed. On every livestream they would ask when it's going to be fixed, and keep asking, and keep asking. And understandably so, because they love it.

    The problem is Cryptic simply doesn't have the manpower to fix both their normal content (episodes, TFOs, various other things) AND this whole other system. Heck, they don't even have the manpower to fix their normal content now.

    The simple fact of the matter is Cryptic decided to remove the foundry not just from STO but ALSO from Neverwinter because they decided they no longer wanted to or simply couldn't support that system. As much as that sucks, it also isn't going to change because someone posted their idea for an unbreakable system on the forums.

    Lastly, while I don't mind people spitballing their ideas, the foundry is a sore spot for many folks. And every time someone has some 'brilliant' idea for how to bring it back, which reasonable people realize is NOT going to happen for all of the reasons mentioned above, it's like picking the scab off.

    Tl;DR; no, your system would not be unbreakable. It would break. And no, the foundry is not coming back. It's sad, but it's true.


    The-Grand-Nagus
    Join Date: Sep 2008

    og9Zoh0.jpg
  • captainhunter1captainhunter1 Member Posts: 1,554 Arc User
    I think Sirsitsalot has a valid argument.

    One of the best things about STO was the Foundry - it provided not only a creative outlet for Star Trek fans, but also a FREE source of massive amounts of content for the game.

    Granted the implementation was jinky but the core idea was/is fantastic. If it were completely integrated into the regular game it would be an amazing basis for a content rich exploration system. This is where I differ in opinion from the OP. I don't think we can have a 'separate but equal' Foundry/exploration system. It needs to be part/hard coded into regular game (so that everytime the core coding is updated, the Foundry would be updated as well). However, that would be a monumental feat to accomplish at this point, basically requiring recoding the whole game to weave the Foundry system in as an integral part.

    STO definitely needs a good exploration system - and the Foundry, or a Foundry-like UGC system is really the only way to provide enough volume of content to satisfy the requirements for such a concept. Procedurally generated content, such as that in No Man's Sky, can't really do the job and becomes boing quickly.

    STO has a unique opportunity to use tools it has already developed such as the Foundry, a galaxy wide map system, and so forth and turn them into an exploration system that would be the envy of other RPG platforms. The trick is getting the whole mess to work - and without ideas being presented and bounced around like Sirsitsalot is doing, it is absolutely guaranteed to NEVER happen.
  • thegrandnagus1thegrandnagus1 Member Posts: 4,528 Arc User
    Unfortunately the people who actually made a lot of early systems are gone and the current folks don't know how they work. Plus, those current folks have actual jobs and assignments they already do, meaning they can't just stop their current work to go learn all of this.

    So the question that matters the most is who is going to hire these new employees that are going to have to A: figure out how all of this stuff works, B: get all of his up and running and C: fix it when things do break?

    All the cool ideas in the world don't mean anything unless you can address that main issue.

    The-Grand-Nagus
    Join Date: Sep 2008

    og9Zoh0.jpg
  • darkbladejkdarkbladejk Member Posts: 2,805 Community Moderator
    Foundry threads are already covered under FCT. Please refrain from creating threads like this in the future unless something were to be released from Cryptic talking about said features. Although I am closing this thread, I think a bit of an explanation is in order on those features so folks better understand why they were removed. It's not really for the reasons people think.

    Exploration system: This was intended to be a stopgap feature and was not intended to be a permanent thing. This was created in the game's infancy and was not meant to always be a permanent thing. The system behind the exploration mechanic would pull bits and pieces from a pre-defined set of possibilities to give the illusion of a randomly generated encounter. After playing through said system enough you would start to notice certain repeat scenarios and pieces, but with slightly different alien-gen toons or similar. This is much similar to how some seeding systems worked in older games to generate a random encounter. It would pull pre-defined bits of map, along with the other needed resources to generate a random mission. Star Wars Galactic Battlegrounds is one example of this. If you ever strolled into the map editor of that game and looked at the various seed codes for certain maps, you would notice several are nearly identical but with maybe small bits interchanged. A river might be on the left side of the map vs the right side or down the line. Given enough potential puzzle pieces to mix and match like Legos, if you have 1000 Legos of different sizes, colors, shapes, etc you can put them together in quite a few different combinations. However if you play with them enough, you will eventually exhaust all of those combinations and have to either add more Legos to the mix if you don't want repeats. The thing that makes adding more pieces hard is you have to define what those pieces are, and take into account how those pieces could potentially be used to avoid issues with previous pieces. The old game Spore is another example of this that becomes blatantly obvious the moment you hit the space stage and fly to enough planets, you will notice how many of the planets are similar or even outright carbon copies of another with slightly different names. The Exploration System in STO could be fun, but was extremely limited in what it could do. Another issue with this feature was that folks frequently got lost in the Star Clusters looking for various duty officer assignments or similar. The doff assignments in these clusters were left because they provided value that could be carried over once the system was removed. Overall it was never meant to be permanent.

    Foundry: The problem with the foundry was that the way it was coded, it was essentially a mod tacked onto the code after the fact, even if it was an official mod per say. Like any mod it must be maintained by the creator(s) if it's to stay functional. The game itself continued to evolve and old code was replaced with new as time went on. However the code for the foundry was largely still based on the same code from 2011. As games get updates and old code is replaced with new, eventually mods can break. I have had that happen with several of my mods that I created for older games. In fact my experience with modding was one of the reasons why I was picked up as a Bug Hunter when that was rolling around the first time. With certain mods, sometimes they can become more trouble than they're worth to fix depending on the break, especially with older code involved. As time went on, more and more of the original foundry creators left the company. So now the new folks were essentially being read into a mod created by another person and trying to make something that complex stay functional. I basically took over development for a mod for another game and it took me nearly 2 years to get it working the way I wanted it to. The thing needed to be largely rewritten in a ton of ways. I say that to give an idea that it's not always a seamless transition. The first year was basically learning the mod. Second year was revamping. Depending on how a game gets revamped, certain mods are no longer possible without extreme alterations and similar to keep it rolling. At those points its often easier to scrap and rebuild from scratch. It's not that they wanted to retire the thing, but that it became too cumbersome. Just like an old car motor with too many miles on it, eventually it gives out.

    While it sucked, this also opens up the possibility they could do a larger better foundry down the road.
    "Someone once told me that time was a predator that stalked us all our lives. I rather believe that time is a companion who goes with us on the journey and reminds us to cherish every moment, because it will never come again." - Jean Luc Picard in Star Trek Generations

    Star Trek Online volunteer Community Moderator
This discussion has been closed.