Singularity: an Eclipse Phase Game

ixokai

I agree with the idea that not bothering with spaceships is a good idea; a lot of the theme of Eclipse Phase is about how big space is. Its a setting in space but its not really a setting about space travel.

I was at one time thinking of making an EP game, but got overwhelmed by the setting choices. So much of how the game plays out rests on where in the solar system the game is taking place. In plots, people can egocast around and end up in any of the zones temporarily, but where you set your basecamp sort of defines a lot about the setting for your character.

And they're all so cool.

Saulot

I love EP, and would be happy to help in any capacity needed.

The Sands

So sort of two steps forward and one step back, I'm going back through some of my code and revising it. Where I use to have your stats determined by your ego, your morph, and your skill (you know, basically how the book has it) it occurred to me to make it so that it is your ego, fork, morph, and skills. Certain things such as traits and moxie are tied to your ego but your actual attributes and skills are tied to your 'fork' (even if you only have a single fork).

This should means there will actually be an ability at the code level for characters to create forks if necessary and should provide a mechanism for backing up egos (a backup is just an alpha fork that isn't running). Unfortunately that means I have to refactor a bunch of code since I was initially looking at the Ego whenever I needed to see what an attribute was. Now I have to look at the ego to see what the current fork is and then look at the fork. Likewise I looked at a table that contained everyone's skills for those skills belonging to the ego (this is an SQL table, not something stuck onto the character object) when I needed to check a value. Now I need to look at the same table but instead of looking for the skills controlled by that ego I need to look at the skills controlled by that ego's current fork.

The Sands

@saulot said in Singularity: an Eclipse Phase Game:

I love EP, and would be happy to help in any capacity needed.

I'm guessing I'm at least a couple of weeks away before I think the code base is really solid enough to have people kicking the tires and things. I was pretty close to having what I would have called a 'runnable' system, but all that means is it could have handled the features that would be needed when you were 'in play'. Doing things like entering a new character would have to be done by hand. However, as I said up above I'm actually taking a short step back in my code right now to better accommodate forks and backups (I'll be honest, part of me isn't even that sure how critical having forking code will be, but I realized if I didn't put in at least some basic support for it then I could have a real nightmare later).

I'll definitely be needing help, though. As I said, I'm still unsure of what the setting should be. The only thing I've really decided is that it probably should be somewhat limited in scope. It isn't that the rest of the solar system or the areas beyond the Pandora gates don't exist. It's just that they will be 'out of town' if this were a more conventional setting (i.e. off grid locations).

I'm going to need people to test code and tell me what's good and what's bad, people to help with the wiki, and people to run spheres (I'm not even sure what the various spheres will be just yet, but I'm pretty sure that type of organization will still end up being needed). And of course there's going to have to be a bunch of building to be done.

ixokai

@the-sands I think you're on the right track as far as setting goes.

Plots (PRP or SRP) can take place via egocasting to whatever place someone wants to run a plot, IMHO. That has the added bonus of balancing the morphs people egocast into with the challenge of the plot. Body hopping on missions is one of the coolest things in Eclipse Phase.

Random idea for a setting thrown at you:

Enclave, a processing locus nestled in an asteroid somewhere -- no one knows where except for Management, for security reasons. Management maintains the simulspace city but its a reputation-based cyberdemocracy, not entirely unlike Titanian Commonwealth, without the Scandinavian socialist parts. Alternative: make it an Extropian colony, and Management is who you signed a contract with to allocate enough processing power to you to run you in the locus.

This might sound limiting at first, because everyone at home is an infomorph, but that's only at the resting state. And what infomorph you take (and how it manifests in the simulspace and what it can do) is important for local jobs.

The Sands

So once more two steps forward and one step back, I've decided to try and code the game in Evennia instead of TinyMux. I've gotten to a fairly developed stage where I am relatively sure I could complete the entire project in TinyMux if I wanted to but I'm concerned about long term support. Even now looking back at a piece of muxcode that I wrote a month ago is painful. The thought that I might have to go back and work on a piece of code two years from now just fills me with dread.

I have to admit to having mixed feelings about leaving mux behind. I did my first MU* coding close to 25 years ago with a tinyMUSH and it's like a pair of comfortable jeans. I'm use to looking at old code and tweezing it apart and figuring out how it's working. Unfortunately with the extra complexity that an EP game is going to require (to calculate your COG you need to know your base COG, any bonuses from morphs or augments, make sure it is less than your attribute maximum with possible adjustments for augments or traits and less than 40 and did I mention a character can have multiple forks and multiple morphs?) I think I want to try using a real programming language like Python and a real data structure like MySQL that supports many-to-one relationships.

ixokai

Isn't that like two steps forward, go to jail, do not pass go, do not collect $200? It sounds like, 'Okay, I am starting over from scratch', I mean. I don't have anything against Evennia or anything.

The Sands

@ixokai Actually, not so much. When I was working on the TinyMUX code I was doing it with a MySQL connection because I didn't see a particularly good way to handle the massive amounts of data involved just using multiple objects. This is because each character can have an indeterminate number of forks, each fork can have an indeterminate number of morphs, and those morphs are all based off of base classes but with customization since each morph usually can choose a certain number of attributes that get a +5 bonus and may have modifications to their base augments (not just additional augments but modifications since a morph might get rid of a standard augment so it can add an augment that would be incompatible with the old augment).

Working out that schema has actually been one of the biggest issues (and there's a bunch of stuff I haven't mentioned yet like the fact that skills and traits have to be recorded two different ways during CG so that you can recognize the bonuses given by your faction/background when calculating how many CP have been spent) but I'm able to move it verbatim over to Evennia (I was so tempted to store just a few attributes on the character object when I was working in TinyMUX but now I am immensely grateful I resisted). Additionally I've already worked out the majority of my SQL calls for checking/setting stats and while I now need to slot those into Python calls instead of the mux softcode they were residing in before they likewise represent a pretty substantial investment in time that is largely recovered.

That isn't to say there isn't a 'step back' component. Certainly I have to take those SQL calls and move them from the softcode into the new Python code as I said, but this is far from 'go back and start over'.

ixokai

@the-sands I know how EP works

IIRC, Evennia's database is driven by its Django component. If you're expecting to do direct SQL in it, there may be more of a pain then you're expecting. Django's ORM is... opinionated.

The Sands

@ixokai Heh. Yes. Evennia's direct database is driven by its Django component, but because command and function programming is done in Python you have access to all Python functionality, including things such as MySQLdb (I have already tested this and it works just fine).

While I have gone ahead and set up my Evennia server to use MySQL to support its core database functions (user accounts, objects, etc.) I didn't actually need to do that. I could have left it using SQLite for the core database while handling the Eclipse Phase aspects through MySQL. This is basically what I was doing during the TinyMUX version so that I would not be storing attributes directly only the player object (or other objects) except, of course, TinyMUX uses its own database format and not SQLite. However I elected to do the core support in MySQL as well so that there is one central DB server handling all data (Evennia core, Wiki, and Eclipse Phase data) rather than spreading it out in multiple places where something might not get backed up.

Coin

Some things you need in a setting for a MU:

a grid for social RP;
a way for storytellers (staff or player) to run stories in the main setting;
a way for storytellers (staff or players) to run stories OUTSIDE the main setting;

Everyone clutch your pearls, but I'm going to agree with @Lithium here: definitely have a gate (make one up, don't feel the need to adhere to canon to build your game) for access to other worlds. Make the gates accessible for plots only--you can't just use a gate to go on a vacation to Venus (unless the vacation is the pretext for a plot). If resources is something that would grant you "civilian" access to a gate, then have it cost something using whatever resources system you end up using. In essence: sure, you can go on a vacation to Venus without it being plot--but it'll cost you resources in-game. Yes, this is abstract. Everything in roleplaying is.

These aren't the only things you need, but they are some basic things. Give players options--but not to many to start. Gauge your playerbase as it grows and start giving them more options later. Pay no mind to people who don't like the current limitations. Make those limitations absolutely clear from the start, and also make it clear that they can change in the future, but you make no promises that they actually will or HOW they will if they do.

And then make sure you listen tio your playerbase and what they want out of the game, because while it is your game and you can do with it what you want, you won't really be able to if you only have ten players who all log on at different times.

The Sands

@coin I'm definitely planning on a grid and a way for storytellers to run stories outside the main setting. Out of curiosity what do you see as different between a 'grid for social RP' and 'a way for storytellers to run stories in the main setting'? Do you mean there should be a grid allocated solely for social RP and it should be off-limits for 'stories'?

My initial plan is to have a main grid as well as the ability to create temp rooms. Temp rooms could either be created off the main grid to represent areas that would exist but had not been constructed (e.g. 'Non-descript Noodle Shop', 'Coffin Hotel', or 'Random Back Alley') or they could be created off the Temporary Room Nexus to represent areas that exist but that lack 'simple' connections to the grid ('A Passenger Transport', 'Meathab', or 'Echo IV'). Most social RP would occur on the main grid but stories would occur on it as well.

I've never seen a game where social RP is forcibly separated from 'story areas'. That isn't to say I'm not going to do this but rather I'm just laying out my plan and experiences. I'm quite open to a different layout if other people have had different experiences and can show that there is an advantage to it.

Two other things that I have to start putting more consideration into are earning money and earning XP. Typically these are both under the purview of the game master running stories but I think I would like to try and make things a little more player oriented. I suppose they aren't that much of a problem. I just need to craft up some guidelines that say that this is the XP/credit rewards for participating/running a story. People submit logs and as long as staff approves the log the XP and credits are doled out.

Coin

@the-sands said in Singularity: an Eclipse Phase Game:

@coin I'm definitely planning on a grid and a way for storytellers to run stories outside the main setting. Out of curiosity what do you see as different between a 'grid for social RP' and 'a way for storytellers to run stories in the main setting'? Do you mean there should be a grid allocated solely for social RP and it should be off-limits for 'stories'?

My initial plan is to have a main grid as well as the ability to create temp rooms. Temp rooms could either be created off the main grid to represent areas that would exist but had not been constructed (e.g. 'Non-descript Noodle Shop', 'Coffin Hotel', or 'Random Back Alley') or they could be created off the Temporary Room Nexus to represent areas that exist but that lack 'simple' connections to the grid ('A Passenger Transport', 'Meathab', or 'Echo IV'). Most social RP would occur on the main grid but stories would occur on it as well.

I've never seen a game where social RP is forcibly separated from 'story areas'. That isn't to say I'm not going to do this but rather I'm just laying out my plan and experiences. I'm quite open to a different layout if other people have had different experiences and can show that there is an advantage to it.

I meant more in the sense that the main setting needs to have value as a source of plot--give it plot hooks, etc., and make sure the storytellers who want to run stuff have access to those. No, don't divorce the social RP from the plot RP (that's ludicrous anyway since a lot of plots could just be social-based and it would make no sense).

Two other things that I have to start putting more consideration into are earning money and earning XP. Typically these are both under the purview of the game master running stories but I think I would like to try and make things a little more player oriented. I suppose they aren't that much of a problem. I just need to craft up some guidelines that say that this is the XP/credit rewards for participating/running a story. People submit logs and as long as staff approves the log the XP and credits are doled out.

I have OPINIONS regarding this and if you want we can get into it but it's gonna take a while (days and days).

The Sands

@coin said in Singularity: an Eclipse Phase Game:

I have OPINIONS regarding this and if you want we can get into it but it's gonna take a while (days and days).

Absolutely fire away. I suspect at the end of the day I'll come up with some kind of hybrid scheme (weekly awards that trickle in to reward longevity combined with participation rewards to encourage people to do more than hang out in an OOC room) but I can't incorporate other ideas if no one tells me them.

Coin

I can't for the life of me remember the system I wanted to implement at the moment but be sure that when it comes back to me I will drop it here like it's hot, XD.

Coin

AH, RIGHT.

Okay, so, very broadstrokes, one of the basic and most prevalent problems with XP in MUing is that you get DINOSAURS who've been around for a long long time and then you combine that with people who are active and create a horrible MECHADINO who not only has XP for being around so long, they are super active and continue to rake it in at a disturbing pace.

Not only that, you have people whose playstyles vary due to preference and lifestyle--people who can play for a month or two very intensely and then be almost completely absent for another month or three because of work, life, burn out, whatever.

So what I propose is an ever rising ceiling to the XP that can be earned in TOTAL. This ceiling rises daily by a very small amount (or very big, whatever the fuck you as the game runner wants).

So let's say on March 30 the XP Ceiling (XPC) is 40 XP (abstract number, I don't know how XP works in EP). The absolute HIGHEST amount of XP ANYONE can have on the game is 40. Let's say the ceiling grows at the rate of 0.5 XP per day. On March 31 it would be 40.5, and on april 1 it would be 50--JK, 41.

Then you simply allow people to rake up XP in several different ways. Let's say you put a +vote system with a limit of how many +votes you can give and receive; then you also give out weekly XP (I suggest this weekly XP actually be daily, since the XPC grows daily--I also suggest that the amount be high for new characters and taper off to something negligible, amounts based entirely on how far away you are from the XPC), and then you give them the ability to get a ton of XP (depending on whatever factors you wanna set) based on running and participating in plots.

What this creates is a system qwhere someone new but very active can actually eventually catch up to a dino, even if the dino has been around a lot longer, because the dino can't advance at the same pace anymore.

It also gives people the ability to play intensely for a few months, (perhaps reaching the XPC), but then go inactive for a while, only to come back and have a much higher XPC, that they can put their energy into reaching via plots, etc.

It's important to have many avenues for acquiring XP instead of just one or two, and have each avenue encourage certain type of RP. +votes probably works for day-to-day social RP, but I wouldn't allow people who are in a plot to be able to +vote for people just because they're in a plot together, etc.

The rate at which the XPC rises should contemplate the rate at which you want the PCs to get more powerful at the ABSOLUTE FASTEST.

If you don't want them to have "more than 500 XP at year's end" then the XPC needs to rise at a rate that won't allow them to have more than 500 XP at year's end.

Make sense?

The Sands

@coin I'm always reluctant to put 'hard caps' on things because I worry that it leads to 'well, there's no point in doing anything more right now' and situations of 'Alex has done twice as much as Bob but the two are at the exact same point because they've both maxed out'. If I do decide to put some kind of throttle on XP it may be some sort of graduated curve.

e.g. Alex does twice as much as Bob but he only has 1.4x as much XP because of the curve. Charlie has done four times as much as Bob and only has 2x as much XP.

The pool might reset from time to time or it could be a permanent 'conversion rate'. Either way players never hit a cap on earning so there's always some reward but there is also a point of diminishing returns whereby the mechadino slows and doesn't completely run away from the more casual player (this wouldn't be as necessary if Eclipse Phase used a geometric system for XP progression but it is a linear system).

Given the core mechanics for EP I'm not sure how necessary it will be, however. The game simply doesn't have mechanisms in which one character is completely capable of overwhelming another. About the closest thing is that there is a pretty strong combat advantage in having a high speed but that is very accessible to people in character generation and it is far from the 'I win' stat that occurs in other games since everyone has the opportunity to take their first action before higher speed people can attempt a second action (excluding someone so unlucky as to lose initiative and then be removed from combat before they can act, but that does not appear to be a common situation).

Additionally because of the setting it is practically impossible for one player to kill another. About the most significant effect one player could have would be to force another to resort to a 'starter' morph and perhaps lose some recently gained skills as they are restored from backup. This removes one of the largest concerns with 'dinos' becoming over powered.

The second biggest concerns with 'dinos' tends to be them dominating scenes and other players feeling unable to contribute. Again, because of the rules of the game that seems extremely unlikely due to the rules for teamwork actions. I do recognize that I have seen players in the past who have attempted to 'teamwork' with themselves through a variety of tricks (multitasking, forks, etc.) which I already plan on disallowing (sure, there's multiple copies of you working on the problem but the copies are unable to offer any significant insight).

I'll have a better idea about how significant the 'dino' problem will be once I've got the coding finished. I'll probably try a short run of a few months so we can experiment with a couple of things (allow a couple of players to make 'high xp' characters so we can judge how well they interact with relatively new characters, see what modifications we might need to make to nanofabrication rules, etc.) before resetting for the 'real' game.

Coin

@the-sands said in Singularity: an Eclipse Phase Game:

@coin I'm always reluctant to put 'hard caps' on things because I worry that it leads to 'well, there's no point in doing anything more right now' and situations of 'Alex has done twice as much as Bob but the two are at the exact same point because they've both maxed out'. If I do decide to put some kind of throttle on XP it may be some sort of graduated curve.

e.g. Alex does twice as much as Bob but he only has 1.4x as much XP because of the curve. Charlie has done four times as much as Bob and only has 2x as much XP.

The pool might reset from time to time or it could be a permanent 'conversion rate'. Either way players never hit a cap on earning so there's always some reward but there is also a point of diminishing returns whereby the mechadino slows and doesn't completely run away from the more casual player (this wouldn't be as necessary if Eclipse Phase used a geometric system for XP progression but it is a linear system).

Given the core mechanics for EP I'm not sure how necessary it will be, however. The game simply doesn't have mechanisms in which one character is completely capable of overwhelming another. About the closest thing is that there is a pretty strong combat advantage in having a high speed but that is very accessible to people in character generation and it is far from the 'I win' stat that occurs in other games since everyone has the opportunity to take their first action before higher speed people can attempt a second action (excluding someone so unlucky as to lose initiative and then be removed from combat before they can act, but that does not appear to be a common situation).

Additionally because of the setting it is practically impossible for one player to kill another. About the most significant effect one player could have would be to force another to resort to a 'starter' morph and perhaps lose some recently gained skills as they are restored from backup. This removes one of the largest concerns with 'dinos' becoming over powered.

The second biggest concerns with 'dinos' tends to be them dominating scenes and other players feeling unable to contribute. Again, because of the rules of the game that seems extremely unlikely due to the rules for teamwork actions. I do recognize that I have seen players in the past who have attempted to 'teamwork' with themselves through a variety of tricks (multitasking, forks, etc.) which I already plan on disallowing (sure, there's multiple copies of you working on the problem but the copies are unable to offer any significant insight).

I'll have a better idea about how significant the 'dino' problem will be once I've got the coding finished. I'll probably try a short run of a few months so we can experiment with a couple of things (allow a couple of players to make 'high xp' characters so we can judge how well they interact with relatively new characters, see what modifications we might need to make to nanofabrication rules, etc.) before resetting for the 'real' game.

Everyone says the same thing about the hard caps (that people will stop doing things because they won't see the point of it), but that has never been my experience. Like, I've never seen someone go "I'm not going to play anymore because I can't get more XP".

In any case, you can always replace XP with something more temporal (perhaps other types of rewards that are "spendable" IC but once spent, that's it) so that people can continue to acquire things even if they are at the cap.

The Sands

I just want to say that I really hate modular flexbots right now. I can easily calculate the stats for a character on the fly by looking at their current fork, their morph, and any augments or traits on the morph as long as it isn't a modular flexbot.

Now I have to update the code so that when I look at the morph I see if there are any additional flexbots attached, check all their augments, figure out which bonuses stack (such as two cyberlimb plus but not a third cyberlimb plus), find the maximum morph bonuses and aptitude maximums between all the modules, and then go through the whole headache-y process of finding which module has the highest durability and then adding half the durability of every other attached module.

On the upside, Evennia lets me make calls to MySQL Procedures properly meaning I don't need gnarly SQL calls in the middle of my Python code. TinyMUX wasn't allowing me to do that which was making me write horrible unformatted SQL calls right into mux softcode.

Auspice

How is progress on this?

Any new updates? Anything that could be done to help out, perhaps?