Design pillars and principles #7
No reviewers
Labels
No labels
Complexity
High
Complexity
Low
Complexity
Moderate
Kind
Alteration
Kind
Discussion
Kind
Proposal
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Significance
Major
Significance
Minor
Significance
Moderate
Status
Blocked
Status
Needs Review
Status
Untriaged
T: Community
T: Direction
T: Narrative
T: Sound
T: Systems
T: Technical
T: Visuals
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Blocks
#5 WIP: Narrative premise and setting
ellipse/docs
#6 WIP: Character traits
ellipse/docs
#9 WIP: Control scheme
ellipse/docs
#11 WIP: Environment and gameplay
ellipse/docs
#14 WIP: Improved combat system
ellipse/docs
#15 WIP: Artstyle documentation
ellipse/docs
#16 WIP: Visual principles
ellipse/docs
Reference: ellipse/docs#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "veritius/ellipse-docs:dev_2025-09-02_design-pillars-and-principles"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WIP: Design pillars and principlesto Design pillars and principles44feda7997toe031905719I think I really like this! I'm not sure if there's anything I can think needs improving.
idk if any of this is helpful because i've never reviewed a design doc before but i hope some of the feedback holds substance
@ -0,0 +11,4 @@The player should, as much as possible, be acting as the character does. They should have enough time to think about what their character would do, in a situation where it matters. It's okay to surprise the player and force them into fight or flight, though. The player is ultimately human, and those moments can cause mistakes that lead to interesting narrative outcomes.Inconsistency and friction in out-of-character decision-making used to inform character actions, should be minimised as much as possible. A situation where taking an action that would be accurate to the character, but isn't fun to the player, should not occur.already said, but this part is confusing and seems like it could contribute to metagaming
@ -0,0 +18,4 @@## Taking it SlowThe game should be paced slowly, giving enough time for complex roleplay and interesting character moments, while still always having something to do, and systems and gameplay to dig into and enjoy.Despite slower pacing, at no point should nothing be happening. There should always be *something* to pressure players into action, and something that everyone can do to contribute, regardless of their chosen specialisation.this is good, people should never feel like they're actively starved for content
however, this needs to be handled in a way that doesn't make it feel like taking long periods of time to RP is "slacking off", or causing issues
further thought put in, the idea of slacking off is not bad in of itself? having someone ignore what they technically SHOULD be doing to talk to people is very human
however, this still leaves the issue of people making other's lives harder by taking a break. if someone wants to slack off, should that cause issues for other people, or just the player? if it's just for the player, what's to stop an engineer from doing the bare minimum, and only suffering the consequences whenever they (rarely) Interact with their actual occupation
i realize that the whole game's systems will be changed to at least some degree, but it's worth considering anyways, and the only lens i have to consider it through is the SS14 that i do know
as it stands, engineering is a very easy job to completely ignore, and feel bored in, because you set up the TEG / singulo / tesla and have to, at most, go spend 3 minutes upkeeping it every 30, and do nothing else besides repairs
how do you avoid both leaving people bored, and making everyone else's life harder because someone takes a break for an RP moment?
The way I wanted things to go is that the speed at which a task is achieved is dependent on the number of laborers. It isn't necessarily harder, just slower, but individuals still performing the task should be able to work harder to match the same pace as if they had more laborers.
I think this isn't about making a perfect system where every case is covered, because I don't think that's possible, but instead, I want to try to get the human players to establish a self-balancing system. When needed, humans should self-assign to important tasks to support the community, like defending the colony during a wave attack or something, or doing botanical work when food supplies are low.
@ -0,0 +20,4 @@Despite slower pacing, at no point should nothing be happening. There should always be *something* to pressure players into action, and something that everyone can do to contribute, regardless of their chosen specialisation.Additionally, respect the player's time: every step of the process of doing something should be rewarding in its own way, or lead to a reward. There should not be a situation where a player is made to do something that is tedious or irritating, unless that situation will lead to an interesting narrative outcome.i think making a process without any tedium whatsoever, while also being rewarding, is kind of difficult?
like, for example, i would call refilling singulo plasma cans tedious, however it leads to a rewarding outcome (powering a station)
this could be personal preference for sure, but i enjoy tedium when it is something other people can notice and feel appreciative of
there is value in tedium, i think that trying to remove it entirely will end up with more problems than solutions
I think this is a good criticism, but I want to clarify that I don't want to completely remove tedium. It's useful as that thing you push past for the reward, feeling bad to feel good. It's a very fundamental tool and I definitely don't want to entirely discard it. However, a lot of stuff in SS14 is tedious with little reward to back it up, like chemistry. I don't feel any reward when I do chemistry, it feels like a chore, and I attribute that to it being an obligation that's necessary for medical to function.
One thing I really, really don't want, is a grind. I want a constant resource upkeep to keep the colony running, but I don't want it to be a chore to go out and collect things. Rust does that, and I don't think the game is any better for it. Nobody wants to go out and farm resources, they want to go shoot shit and raid people. It's not the experience you're there for.
this is one thing that i think is more opinionated, because i personally really enjoy chemistry
i like the feeling of a job well done, even if the job is a series of steps that i've done before. there's no way to stop people from getting used to and perfecting their jobs in this game, and sometimes that's the joy of it. chemistry is fun because i know that i make other people's lives easier by being good at my job
now, i do think that if you have systems like chemistry, you can add more to spice up the experience beyond what you need to do. chemistry lacks substance when you finish making medical chemicals
the reward of chemistry to me is feeling like i've done well, but that's still leaves you with nothing to do after
i think the best idea for it is not to remove tedium, but to add something to break up the tedium after it's been done, like you said. there should be rewards for "tedious" tasks, that feel good
say for example resources, i don't think it's that bad for that to be a chore? but give someone a reward after, and that's how you make it feel engaging
Not liking Chemistry is definitely an opinion, and it's a symptom of its current state. I'd be fine with keeping it as a game system if it were modified, but right now, it's one of those things that I find very unsatisfying.
@ -0,0 +23,4 @@Additionally, respect the player's time: every step of the process of doing something should be rewarding in its own way, or lead to a reward. There should not be a situation where a player is made to do something that is tedious or irritating, unless that situation will lead to an interesting narrative outcome.## CooperationPlayers should be encouraged to act cooperatively, both in small teams and as a whole. Any conflict between players should be purely due to individual character narratives, like conflicting personalities and ideologies, and not a result of game systems causing competition and infighting. In short, players shouldn't fight over who gets the shiny rock.communism is great, don't get me wrong, but i think a part of working as a team (especially in fictional setting where characters can conflict greatly), includes feeling frustrated because one person is prioritized over another
people should not argue over a shiny rock, but i think interesting conflicts can come out of limited resources, and being forced to prioritize some people over the other
however that can very easily spiral into ooc frustration, and favoritism, SO idk. i both do and don't like the idea of having conflict be entirely character based, rather than system based
extra note, system-based conflict can be a great springboard for character conflict. sometimes you have characters that get frustrated with eachother over something related entirely to their jobs, and that can turn into interesting motivations or each of them later down the line
I think this is the weakest point of the document. I find it difficult to identify how it would be even possible to achieve a balance between "player-driven inter-character conflict" and "system-driven inter-character conflict that's fun". I don't think I have the experience to address this issue, so I went for a conservative answer, which is just to go for what I know will work fine. The game will be worse for it, but as it's so core to the game's design, I don't want to risk making things worse while the rest of the game is still so early in its creation. However, it is definitely something I want to return to later when I have more experience.
i think making character conflict, that is caused by systems, fun and not frustrating, is absolutely one of the hardest things to tackle
coming back to it later in development is absolutely better than an imperfect solution that becomes baked into the design
If this document is merged in a state where it specifies that system-driven inter-character conflict is not desired, I'll make a tracking project to monitor the idea over time. It's something that deserves testing, and that can happen later on when there's a game to work with.
@ -0,0 +29,4 @@Players should not have to compete for something: anything usable by the player should not be unique. Instead, it should be (relatively) easy to reproduce, depending on progression, making sure that everyone gets a go, and nobody feels left out. It's natural to resent repeatedly missing out on the fun thing, so the game should ensure that such a situation is extremely unlikely to occur.Players must not be able to operate purely individually. It should be nothing short of a death sentence (and not fun) to try and run off alone into the wilderness to try and build your own colony.when taking in mind the previous goals of having nothing be unique, and having little to no tedium in systems, i'm not sure how this would be accomplished?
obviously a player can figure out every system given time, so it can't be knowledge limitations. if there are some constantly time-consuming processes, that is both tedious and antithetical to allowing everyone ample time to RP and interact
it not being fun aside, i'm not sure how it would be managed to be a death sentence, ESPECIALLY considering that ellipse will absolutely be lowpop for it's beginning, and likely much of it's early life at least
when the population will probably be balancing around 10-15 people, how do you make it so that jobs cannot all be done by the same person, without forcing some players into constant maintaining and upkeeping, and giving them no time to rp
i think that people being forced to work together is GOOD, don't get me wrong, but i'm curious how this would be achieved
@ -0,0 +40,4 @@The responsibility of dealing with the consequences of a player's actions should lie with the player that made the mistake leading to the issue. For specialisations that involve having to deal with some of the consequences of someone else's mistakes, like medical, the player that fucked up should still suffer consequences that other players cannot address.One of the end results of this is that **death should be meaningful.** Players should be afraid of dying, and as a result, not play in an incredibly irrational way that no real person would ever do. Intentional deaths should be a rare, deeply impactful character moment, not a regular occurrence.death being meaningful is GOOD, people should be afraid to die
actually enforcing that though is a whole other thing. if you decide that as a consequence of death being meaningful, it should also be largely avoidable, then death will be something that mostly affects new players, while the best players completely avoid it and never suffer the consequences
if deaths are kept as the currently are in ss14, it is far too easy to die with little to now possibility to counteract it, and if the result of that is permanent RR, or something close to that, it would not be fun from an ooc perspective. RP aside, dying without counterplay and being forced to spectate the rest of the multi-hour round is not fun
How this stuff is implemented isn't relevant to the document. This is the core document that the rest of the game is designed around; the principles underlying everything else. This is what we want - whatever happens to achieve that is a different task.
@ -0,0 +47,4 @@Individual systems should be simple, intuitive, and able to be explained easily. Complexity should arise from the interactions between systems, and able to be understood by the player based on their understanding of individual systems. The outcome of this should be that no part of the game is so overly complex or obtuse as to be impenetrable to newcomers.Systems should incentivise social gameplay above singleplayer gameplay: while parts of a gameplay loop or mechanic can be achievable by a single player, the game should always encourage cooperation and social interaction.already said earlier, but encouraging cooperation is very different from enforcing it
it may be easier to work with other people, but with sufficient skill and time put in, how do you stop someone from working entirely alone anyways?
Implementation is irrelevant: see here.