I've been having an idea bouncing around my skull about how an SBURB-esque game would work in real life. That is to say, obeying our laws of physics, that is to say, not actually a game that warps reality. An actual game, in other words.
My idea for how the game would be played is kinda like a LAN game, but it could be adapted for a true Online experience. For a LAN game, there would be one computer running software that would just be for keeping track of all the happenings, prototypings, anything that changes in the game world, etc. The other computers would be running software that could connect with the computer running the Medium software, that first computer.
My idea was that instead of importing and exporting huge huge files, the program loaded on the player's computers would be fed a string of characters which it would interpret as conditions in the game, and then construct levels and shit locally. Of course, the string would probably be several hundred, if not several thousand characters long if it was keeping track of every thing that could change. Perhaps the controller computer could tell the player's computer to keep certain parts of the string, while replacing other parts that change more often. Thus, things that don't change often, or don't change at all, wouldn't have to keep getting sent back and forth.
The game would play out something like this: controller program is started, and awaits connection from Player computers. Obviously, a computer cannot run both controller and player programs at the same time. The players connect. The game can only be played with an even number of players. Once all Players are connected to the controller, the controller writes the starting conditions of their session. Now, I'm not a nice person, and SBURB is supposed to be a difficult game, so I'd set it up so that 9/10 sessions are null from the start. Of that 90%, 1% would be void sessions. Other things the session builder would take into consideration:
1. Assigning roles
2. Building player homes, and placing items in the homes
3. 1/10 chance of First Guardian being non-sapient pet of one player
4. Assigning other special variables
Probably, the first iteration of the game would let you choose between being Trolls or being Humans. Future iterations would assign a race randomly, and would probably have a larger pool to choose from. On the player side, players would design their character's looks, choose a sylladex and a strife specibus, and choose a chumhandle. The order for entering would be chosen randomly.
Time shenanigans would be difficult to deal with. Possibly, as part of the pesterchum/trollian system, you could choose to make your timestamp say you're IMing from the future or the past. While it wouldn't change things in the real world, the game could interpret the timestamp and affect the gameworld in such a way that it has happened or will happen at the appropriate times. I dunno how you would do that, though. Now, for time players, things might be a little easier. Perhaps, if a player does something that blocks proper completion of the game, the time player would be given a prompt telling them to go back in time, and, upon fixing what went wrong, they would gain control over their alpha timeline self. Their doomed self would be taken over by the AI, and eventually it would die. For time hops that stay on the alpha timeline, perhaps it just reverts their iteration of the gameworld to the point they hopped to, and then their old self follows the same actions they already did, until it's time for them to timehop. Or perhaps the game would have to railroad time players very carefully, so that they can only go back in time if they see time clones running around already. Their timeclones tell them when to go back in time, and so they do so. Personally, though, I dislike railroading the player.
The most difficult part of the game would definitely be prototyping and alchemy. Because of the massive list of things that can be created, this would take up a huge chunk of the controller program's size, to be prepared for just about anything. Most likely, if a players attempts to alchemize something, the code of the item in question would be sent to the controller, which would check against a list of items. If the item in question is on the list, the controller sends back the grist cost to make the item, and the player can make the item. If the item can't be found on the list, the game sends back a Perfectly Generic Object. Obviously, this limits players somewhat, though I imagine an imaginative programmer could be prepared out to the 5th or 6th level of combination. Though, once again, that's a huge number of data points. Searching that many data points for one specific match would probably take several seconds unless the code was well optimized. As for prototyping, that might actually be easier. The biggest problem would be designing art assets, unless there was some way to make changes to the sprites on the fly. By which I mean the game sprites, not the Sburb sprites. The game would also have to be able to procedurally generate the sprite's speech so that it makes sense grammatically and is appropriate for the individual players.
I think that covers every thing the game has to do. If you read all of this and think I missed anything, let me know. Obviously, this is mostly just navel-gazing, not actual concrete plans. Maybe someday, though.
Poll
Author
Topic: MSPA Homestuck (Read 5229028 times)