So, to summarize all discussion that’s been had up to this point… this is what I’m thinking the Kupopolis presence on the web is going to look like once all’s said and done:
•Moogle.Club - This discussion board will exist apart from the main family of Kupopolis.com websites.
•Kupopolis Yahoo Group - Email discussion board, active and lying in wait in case of another community-breaking emergency.
•Splash/Login/Landing Page - Logging in here will allow access to everything else.
-Archives - Contains the contents of the old Sliver boards – maybe entirely as they are? Maybe archived in a different form? Accessible only to Kupopolis members.
-New Proper Message Boards - For the shiny new iteration of Kupopolis, with auto-tagging and map features that sync with Kupopowiki.
-Other hosted ISes - Using the same code and format as above, with the same neat features.
-New KupopoWiki - Designed to integrate with the new message boards. A long-term goal is to have us standardize all like wiki articles (character profiles, nation profiles, organization profiles, etc.) to a single format. Articles on the wiki would be devoted to keeping track of stuff from Kupopolis Proper, Kupopolis Neo, Kupopolis Legends, and any other stories we host as part of the Kupopolis community.
-=-=-
With that rough sketch out of the way… I have some questions I want to pose to the community.
-What would our first non-Kupopolis hosted IS look like?
-Would it be time-limited? Perpetual? Or would it last until it comes to a natural, organic conclusion? (remember that Neo was supposed to run for a year, but it was extended so that it could have the ending it seemed to need)
-Do we elect someone from the community to “run” the story, the way that NOA would appoint someone to “run” their stories? (by “run,” I basically just mean establish a backstory)
-Do we open the hosted IS up to others (like the many guests we’ve had participate in Iron Writer), and, if so, does participating in a Kupop community IS get you “full access” to all the Kupopolis archives? Should there be different layers of membership depending on how deep into the community you want to go?
… Do you guys want to kill some time by just writing something quick and dirty together on moogle.club? I mean apart from the Iron Writer Haikus we’re going to be getting eventually.
I figure we get some proposals from those who already have a pitch, or if nothing is forthcoming or drawn to, we brainstorm something everyone interested can get behind.
I say let the story organically end, unless part of the proposal is a time limited aspect that has either a mechanical or story related effect on the project.
The accepted proposal (if we have one) would probably dictate at least a background/set up from the originator of the idea for example: Mike suggests a Fall Out like IS, with a stash of nukes buried in the core giving us an unseen doomsday clock. We like it and decide to do that as a 2 year project. Mike is then responsible for establishing a bit of the setting and history, and then we all play.
I’d be all for opening access to the offshoot, if others are. It feels… Safer, since its a clean slate.
I would probably limit Kupop access, at least initially, but once we let someone into the archives, we may as well grant writing privileges (if that’s what you’re referring to), because I think most people would want a piece of that pie once exposed.
And unless we get started soon, I’d love to do something quick and dirty here.
[quote=“Scen”]-What would our first non-Kupopolis hosted IS look like?
-Would it be time-limited? Perpetual? Or would it last until it comes to a natural, organic conclusion? (remember that Neo was supposed to run for a year, but it was extended so that it could have the ending it seemed to need)
-Do we elect someone from the community to “run” the story, the way that NOA would appoint someone to “run” their stories? (by “run,” I basically just mean establish a backstory)[/quote]
My thought is, let’s let the person who gets the idea basically “run” the IS (run in the sense that you’re using it, Matt, IE makes up the backstory and maybe occasionally pushes things forward).
I’d say yeah, let’s have the IS open to people who just come in or show up. I’m with Byron on this one.
My leaning is that we can extend an invitation to Kupop if they seem interested, but let’s maybe not make it codefied. That way, if they don’t give a rat’s ass about Kupop, hey, no big! And if a prolific new person wants in a month into the IS, we can just toss them the keys to the party van.
The only thing I would add is the login splash page would be only for the archive hub. Ideally the new ISes will have their own privacy settings and most likely a different account list. That seemed a bit fuzzy in matt’s description.
Now, is the new IS system standalone like say a WordPress install (and possibly open source), or say a network like tumblr? Do we need sperate accounts or will one login work for them all?
[quote=“michael”]The only thing I would add is the login splash page would be only for the archive hub. Ideally the new ISes will have their own privacy settings and most likely a different account list. That seemed a bit fuzzy in matt’s description.
Now, is the new IS system standalone like say a WordPress install (and possibly open source), or say a network like tumblr? Do we need sperate accounts or will one login work for them all?[/quote]
That makes sense, with the new ISes having their own privacy settings and account list. As to whether the new IS system is a standalone for each story or a network… I’m not sure, really. I guess my leaning is one login for all of them; that seems cleaner and better for building communities.
Actually, rereading that, are we placing the old archives, the comics, any other stuff in the new locked archive too? We can do that. l’m thinking to follow best practices that tex described, we create a directory page in the archive section that links to these sites in sub folders. May need to talk to Dustin about it.
Yeah, I’d suggest that; it puts it all in one places, any potential issues are resolved, and also no one’s gonna get the comics if they weren’t in Kupop.
[quote=“michael”]The only thing I would add is the login splash page would be only for the archive hub. Ideally the new ISes will have their own privacy settings and most likely a different account list. That seemed a bit fuzzy in matt’s description.
Now, is the new IS system standalone like say a WordPress install (and possibly open source), or say a network like tumblr? Do we need sperate accounts or will one login work for them all?[/quote]
Well, the way I’d put everything together in my head, everything that we’ve been talking about to date (the new Proper board, the archives, the wiki and any hosted ISes) would all be linked to a main index page that was, ultimately, behind the login page.
Similarly, I sort of assumed that the new hosted ISes would have all the same bells and whistles as the new Proper board, especially integration with the wiki. I also was sort of assuming there was one singular Kupopolis account, but my question on that was whether a new person getting that account for the hosted IS had full access to everything in Kupopolis, or if we implemented a “layers of access” scheme like Gabe was talking about.
What I was thinking was old stuff gets locked away with a login system and its own separate login page. The new ISes will either get their own individual logins, or a unified login system. Not sure where we said the new stuff would be locked away as well, but I think that should be an option per IS. Dustin had mention he was hoping to one day make a framework that others can use, and I’m inclined to keep the software in a presentation that is in some form publically visible.
Moving forward I feel that we have three goals: secure and archive the kupopolis legacy of stories for the veterans, create activities that are fulfilling for our established community, and continue to develop the community for like-minded individuals who are interested in growing and expanding shared interactive stories. I feel that we could be fine making the new Kupop a sign-up only kind of engagement, but I also feel that at least one IS should be wholly available to the public so that people can get a feel for what kind of activity this is. I feel that the later would keep with the vision that Dustin and I shared when I first started helping him with the front facing part of silver.
Also I’m thinking the “layers of access” scheme would be for the archives only, up until the IS is retired (if they have end dates). At that point the original writers could modify levels of access.
To be honest, I wasn’t really thinking of levels of access on the new boards, because with the map/wiki/timeline integration, that sounds like it would break the damn thing and I’d get lost in QA hell. Mooggie don’t like QA hell.
[quote=“michael”]Also I’m thinking the “layers of access” scheme would be for the archives only, up until the IS is retired (if they have end dates). At that point the original writers could modify levels of access.
To be honest, I wasn’t really thinking of levels of access on the new boards, because with the map/wiki/timeline integration, that sounds like it would break the damn thing and I’d get lost in QA hell. Mooggie don’t like QA hell.[/quote]
I think you may be right about the hosted ISes… and, maybe new Kupop, too. But, I’m fine with just the archived stuff going behind the login page.
However, Mike: was I right about the hosted ISes using the same board layout (with mapping and timelines and such) that Kupop will? And, along with it, use of KupopoWiki?
Yes on the same layout, but with preferences. Like maybe they’d refer not to use the map, the timeline, or have certain features run a certain way (like randomly adding locations, or just adding them via mentions in the story, or both).
They’d also have their own variation of the wiki, so there wouldn’t be a shared wiki. Its all one bundled package in my mind.
Start with the backbone features and build up from there. The Board > Location > Thread > Post abstraction used in the last version of Sliver works well and should be the first things built out. It also makes a great foundation to build from, as any time a feature comes up you can decide what level to implement it on.
Once you have that done, start looking into your more fantastic features. The procedurally generated map is a brilliant idea, but probably one that will require beta testing and iterative development that could be awkward to polish if you’re trying to run your alpha at the same time you’re writing a new story. If anything I would highly recommend having some miniature story to test out the idea and work out the kinks, otherwise you might find yourself super sad when your newly rollesd adventurers are forced to explore “The The The The Forest” or your entire map gets filled with nothing but mountains. Wiki integration can likewise be added after the plane is in the air.
Use a framework. Leverage as much prewritten code as possible. When I first made Sliver, not only were there limited reusable resources out there, but I was also dead set on building most parts myself because I was eager to learn. This was a blessing for me but a bit of a curse for Kupop development at large. And once the years went by and I started using outside modules in Sliver – like TinyMCE for the text editor or jQuery for the front end – those aspects became better rapidly. Use something like Rails for the nuts and bolts, something like bootstrap + Jquery for the front end, etc etc. I’m sure Mike can appreciate what I’m talking about here.
Opensource and it and put it on GitHub. Make the software (not the story content) downloadable and deployable by anyone. Make any one install capable of hosting any number of I-Stories, from 1 to 1,000,000. Welcome contributors while keeping a tight rein on the vision for the main branch. The day may come, though it may be months from now, where I’d want to contribute myself.
Separate the front page of the site at large from the board app itself. Just do some kind of CMS install for the front page and don’t worry too much about integration with the new boards – just have a link from the CMS that takes you to the boards, whether it’s a default board or a list of boards to choose from.
A project like this is one I’ve pondered many times in the past so I’d love to see it done right, but I’m definitely not currently in a position to do any heavy lifting. But a solid, humble start will mean anyone – myself included – can jump in and hit the ground running.
That all sounds excellent Dusty! Also all pretty much what I was leaning towards. Initially the “protokupo” was to be the an attempt of the backbone you mentioned, but now it seems the discussion is going note towards what you are thinking.
The framework I was thinking was laravel for the back end and angular.js for the front, with the map feature being create.js. I was hoping to pick your brain on the best practices of building a app on top of a framework and putting it on github, as most of my repo commits have been complete deployment ready packages and not geared for custom installation. This seems down the line though!
Also, I do have one other pet project I’m collaborating on, and I don’t want to drop the ball on the that (matt has seen the prototype). The next iteration of kupop won’t be done overnight, but I think it’ll be done right.
This is the one thing I’m most concerned about as database structuring is my weak point. Do you feel that the current data structure would permit for this, or do you think adjustments would need to be made if we get 5+ stories down the line and years of use behind it? (I was thinking of using the current table structure as a basis, which was holding me back from starting this sooner, as I haven’t had a copy of the DB to look at until now).
The abstraction above, provided it’s well indexed, should be able to easily scale to millions of posts without any kind of big performance hit. The real costs will be what gets built on top of it.
“Unread Posts”, for example, was easily the most expensive feature in Sliver data wise. I dunno if any of you remember the sometimes outrageous load times on older versions of Sliver, but that was all due to the Unread Posts count. If I was to build that feature again today I would do it differently (and a whole lot more complicated-y), but the main point is that it’s the features you’ll build on top of Boards > Dimensions > Threads > Posts that will affect scaleability. The foundation itself (if built properly) will scale beautifully.
(In probably won’t scale beautifully on a modest little VPS, but if you’re getting up to millions of posts and thousands of visitors you’d better be on AWS or some such by then.)