Friday, May 13, 2011

Unnecessary MMOGification

Today, the gods of gaming smite me, forcing me to hypothetically force my game to be an MMOG. Watch as I tear it to shreds.





1. How do you plan to deal with the issue of new players arriving in the middle of
a long game? Get rid of the victory condition, or find a way to make sure that players are matched with those of similar ability?



The nature of my game actually makes this fairly easy. The player is just an anonymous drone, violently tossed out of tubes into the world. Adapting this method of entry to an MMOG is easy, just spit out multiple drones. My game currently centers itself around exploration and puzzle solving, so making it non-linear is a bit out of the question, so instead, I would just adapt the puzzles to require more than one player at times, and to be more difficult, making players work together to reach a victory condition. Due to the fact the player can cooperatively win the game, they would essentially be running through instances of the game over and over, so to achieve persistence, the players gain experience used to slightly modify stats, or unlock small cosmetic changes to their avatars.

2. What will happen to the gameplay when a player vanishes? How will it affect
the other players’ experience of the game (what they see and hear)? Does it disrupt
the balance of the game? Will it make the challenges easier or harder? Is the game
even meaningful anymore?



Again, since players are just drones, they can simply explode and de-spawn upon disconnect, they're going to re-spawn the same way, whether they died or are connecting to the server again. Since puzzle difficulty and complexity would scale with the number of players present on the server, if the player count drops to a level where the current puzzles aren't possible, I would either design the game such that puzzles can be dynamically changed, or force the current instance of the level to die and reload once suitable for the amount of players. Dynamic puzzles would be more difficult to design, due to their restrictive nature, however reloading the world and having the present players lose their progress can get annoying. If I were an engineering god, I would go with dynamic puzzles/worlds that change with player count.

3. What happens to the game’s score when a player vanishes? Is the game still fair?



Fairness doesn't change as players leave/enter, since they are cooperating rather than competing, if you disregard griefers and non-active (AFK) players for a moment.

4. Does your game offer a player an advantage of some kind for intentionally disconnecting himself (whether by preventing himself from losing or by sealing his
own victory)? Is there any way to minimize this without penalizing players who
are disconnected accidentally?



There would be no disadvantage to player death, or failing to solve puzzles, so they have nothing to gain by intentionally or unintentionally disconnecting. The only way of increasing experience is to complete world instances, which is only used for cosmetic changes, and insignificant stat boosts (for example, maybe a 3-5% speed increase, just for fun). Accidental disconnection means that a player potentially misses out on this experience, which doesn't make the game easier or harder, just creates a feeling of persistence.

5. In a turn-based game, what mechanism will you use to prevent a player from
stalling play for the other players? Set a time limit? Allow simultaneous turns?
Implement a reasonable default if the player does nothing?



My game would be real time, since a turn based platforming/adventure/puzzle-solving game would be confusing and incredibly unentertaining. Hypothetically though, if I were designing a turn based MMOG, I would implement a time-limit to player actions, but allow them to make these actions simultaneously. Once both players select their actions, they are executed at the same time, so the longest amount of time a turn can take is a single time-limit, not the sum of the time-limits of each player.

6. If you offer a chat mechanism, what features will you implement to keep it civil?
Filters? A complaint system? An ignore system? Or will your game require moderated chat spaces?



My chat mechanism would be two-part. The immediately present system of communication would be a set of predefined action requests, such as "Press this lever," "Destroy this enemy," or "Open this door." When a player performs one of these, all other players see your requests, and don't have to put up with a bunch of people saying "open the door fagz." Of course, people often need direct communication to get ideas across to each other, so players would be able to request permission to chat with one another, then each would be presented with a text-based chat interface from where they could call one another "fagz" all day long.
7. Is your game designed to prevent (or alleviate) collusion? Because you can’t prevent players from talking to each other on the phone as they play, how will you
address this? Or can you design your game in such a way that collusion is part of
the gameplay, as in "Diplomacy"?



By nature of the game, collusion wouldn't be too large of an issue, since players can't actually attack each other, but there are still plenty of ways for them to mess with one another. 


One such case would be locking players out of rooms with doors that can only be locked one-way. This gives one person too much power over others, they could literally lock everyone but themselves out of a room, essentially stopping the game from moving forward at all, so, this is a big issue. The only real way to deal with the problem is to eliminate doors with such behavior, making doors permanently remain unlocked, via switches that can only be thrown once. This still allows for interesting puzzle solving, without giving one player the ability to screw everyone else over.


Another possible greifing opportunity arises from players just refusing to help everyone out and solve the puzzles. Remember how I said that puzzle complexity scales with player count? If the player count is at the minimum value for the current puzzle to be instantiated, this means that some puzzles can require every single player to work together at some points, which is a big problem is someone feels like annoying others (and this is the internet, assume EVERYONE wants to do this). To resolve the problem in an easy way, I would implement vote-kick system, so that other players can kick the problematic player from the game, thus throwing the game into a puzzle complexity state one notch below its current level. The more interesting solution to this issue would is to use the vote system again, but to allow a selected player temporary control over the problematic (or non-problematic) players drone. This kind of opens up a new griefing opportunity, so I would make the required vote count either unanimously yes, or very close to it (of course the griefer would vote no, and the player being nominated to take control votes yes, so just don't let these two players vote).

No comments:

Post a Comment