Giter Site home page Giter Site logo

Comments (6)

rofl0r avatar rofl0r commented on May 22, 2024 1

my view is that base discovery should be based on realistic possibilities. IMO the most critical phase for discovery is when you build a base, or put new equipment there. if a base is fully equipped, self-sufficient with own power generator and all kinds of stealth technology and fenced off, the chance for discovery should be almost zero (especially in 3rd world countries).

from singularity.

PeterJust avatar PeterJust commented on May 22, 2024 1

In general I'd agree. But I'd rather play a well designed(, maybe simplyfied) game than a complex but realistic simulation. (Thus I prefer Kerbal Space Program over Orbiter.)
At the moment, Singularity is pretty abstract using some interesting mechanics pitched against each other. I would personally prefer the game to stay abstract and not introduce this much detail. Therefore I would sacrifice a realistic discovery model in order to keep the game simple (-> KISS).

So I think the constant discovery rate suffices, if it is well balanced. Making it action-dependent introduces lots of complexity. And the location dependency is cared for by the randomised location attributes. Bonus: This way, current "3rd world countries" aren't discriminated against ;)

from singularity.

PeterJust avatar PeterJust commented on May 22, 2024

This could be one solution. It would punish you for filling up your base though. And I think the whole point of building a warehouse is to concentrate CPU power in one place, in order to generate less discovery rate compared to lots of datacenters. So i think this would kind of contradict the incentive to build larger bases.
I suggest to balance the (constant) discovery rate of the warehouses in a way, that they are usually discovered after having paid themselves off, plus some net profit. This way, you would be constantly challenged to rebuild your "warehouse fleet", while still being able to progress. The different discovery probabilities of the locations and pot luck play a role here as well. At the moment the bases are usually discovered to early (e.g. before they paid themselves off).

If you still want to try reducing the (d)iscovery rate proportional to (c)urrent space usage: d = (d_max - d_min) * c/m + d_min, where m is the (m)aximum space of the base and d_max/d_min define the maximum/minimum amout of discovery rate supposed to be there.

I also have to revise myself from #75 : warehouses are usable at the point the become buildable (in normal mode) IF one doesn't blow the grace period (building more than 10 bases). If you didn't look at the code, you don't know about the grace period conditions, though (which might be part of the game? Singularity doesn't know about the grace period as well). So you could consider it a stroke of fate. But I think the punishment is a bit too harsh, as warehouses become unusable as mentioned.

from singularity.

Quix0r avatar Quix0r commented on May 22, 2024

Maybe have both together? Means, you have 2 models, realistic and abstract/arcade so both parties are having their game they wish.

To accomplish this, you start abstracting your difficulty model and then implement it for both realistic and arcade.

from singularity.

Xenega avatar Xenega commented on May 22, 2024

Realistic and arcade game is another problem. Don't mix it with this issue. (You can open a new issue) For now, the priority is to have a balanced game.

@PeterJust
Non-constant discovery rate will appear sooner or later. In fact, there already modifier but hidden. It's not a problem. Player can have incentive to prefer big base instead of partial bases if the discovery rate is less important for one big base than two partial base. Depends of formula used.

from singularity.

Xenega avatar Xenega commented on May 22, 2024

For now, we will abandon this idea.

from singularity.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.