Dilemma about player-created content in Design Philosophy

ID:151782
 
Apr 16 2009, 1:45 pm
My game is based partly on the idea of an evolving world. NPC cities expand, monster colonies roam towards areas they find valuable (due to resources or other) and players can build and expand cities.

This is all fine and dandy, but presents me with somewhat of a problem when it comes to updating and expanding the world. I'm in the process of building a map editor at the moment, and it occured to me that I'm going to run into issues once the game runs live.

The game runs off MySQL, and to support the map editor I'll clone the main database on a weekly basis to a 'test' database, that the map editor can draw from. This means a level editor can make changes as they like, without impacting the game which runs live 24/7 (outside of patch dates). However -- What if Jimmy decides to build a city in an area where a developer is currently editing a map? Or what if a monster colony decides to migrate off a map that a developer is working on, they push their changes live and suddenly it'll warp back to where it was before!

The way I see it, I have 3 choices. Two of which are very hard to implement, one of which I'm going to have a hard time fitting into the game as it is. Lets start with the easy one:

1) All cities become teleporters from a 'world map'. This means players can't influence actual real-estate outside of their own instance, which a developer should never have to edit. The same goes for 'monster colonies', which become 'points of interest' on the world map. This means nothing editable runs the risk of 'intruding' on something else.

2) I try and cook up a system that does the equivelant of an intelligent diff between how the area looked when the developer checked it out, how it looks now in the live version and how it looks for the developer. I'd have to account for a variety of headache-inducing situations here.

3) I scrap the idea of a map editor and move the map editing tools into the game client, allowing the level editors to edit the 'live' world. This means changes can't be pushed periodically, they'll show up right away - Areas can of course be 'closed off', but that might make the game unplayablee.

Because its the only sane option of the above, I am of course mostly considering #1 so far. However, I wonder if someone has an approach I hadn't considered? :/ If the game didn't include a model of frequent changes, this would be a non-issue.
#1 Apr 16 2009, 3:40 pm
Even with option #1, what if a player is currently in an area that is about to get an update? Does the area around them instantly, magically change? If so, can the player get trapped?

Or do you section off the area (or shutdown the game temporarily) for a moment, apply the update, and bring everything back?

As for ideas...

You could have the map editor not keep track of the current state of the map, but rather the changes that were made. Then, when a human editor makes changes, before you apply them, you could recopy the live database to update the test one, have the human editor's changes show on the updated test-map, and let the editor do one last, quick change manually to accommodate for the recent changes in the live map. If their changes can be treated as a single (or few) object(s) representing all the changes, so that they can drag the changes around all together as a unit, having all the applied changes shifted to the site they drag to, then the fix could be accomplished in a minute or less; probably not enough time for any more major changes to the live world.

Another idea is to have the changes not take place all at once. Depending on what kinds of changes are made, it could happen gradually over a few minutes or hours, accomplished by a system that takes the change-data as an input. For example, if it's a terrain change, it could seem like a natural event; then, if someone built a building in the way, the naturally event just naturally impedes the human development in whatever way you see fit (a river is forming, the human-developed area is flooded, just have the river plow right through someones house, or if it's a mountain erupting, it is demolished). I think this would actually add a fun element to a game. Even if the changes aren't always quite of that nature, most things could probably be accounted for in a similar manner, and we could probably help figure out how if you mentioned the kinds of changes you have in mind. For example, if your human editor wanted to add a new town to the game, you could have a few NPCs magically appear on the map in the vicinity - not a major change at all - and they could labor to build the town as best they can around whatever's happening in the area over the next hour.
#2 Apr 16 2009, 6:33 pm
The solution is simple: bring the game down occasionally to add small updates. I'm sure your players wouldn't mind a couple hours of downtime occasionally! If this is unsuitable, your smart map tool is probably the best idea that actually involves work.
#3 Apr 16 2009, 7:16 pm
Alathon wrote:
1) All cities become teleporters from a 'world map'. This means players can't influence actual real-estate outside of their own instance, which a developer should never have to edit. The same goes for 'monster colonies', which become 'points of interest' on the world map. This means nothing editable runs the risk of 'intruding' on something else.

Of course the easy one I hate. I don't like the idea of a world map because for me it completely destroys immersion. Immersion is something I hold very dearly, even if it is just a 2D game.

2) I try and cook up a system that does the equivelant of an intelligent diff between how the area looked when the developer checked it out, how it looks now in the live version and how it looks for the developer. I'd have to account for a variety of headache-inducing situations here.

Honestly I have absolutely no idea wtf you're talking about here, so I'm not gunna say anything. Except that. And that. And that. And that. ... And that.

3) I scrap the idea of a map editor and move the map editing tools into the game client, allowing the level editors to edit the 'live' world. This means changes can't be pushed periodically, they'll show up right away - Areas can of course be 'closed off', but that might make the game unplayablee.
I don't like the idea of a map editor, again because of IMMERRRSIOnn. I personally would feel INFINATELY more gratified if I had to go chop myself down a tree, saw it up into some planks, then make myself a house wall by wall than if I stood on a tile and typed /iwantawallhere that took away 50 gold.
In this sense I'd suggest looking at a game called RPGWO. Everything (I do mean everything) in the game can be created by a player, and interacted with. You can grab a shovel, dig a tunnel (which takes you to a different Z range underground), grab a mining pick, mine the walls (which actually makes you a 'tunnel', digging into the dirt) get some granite, hammer and chisel out some bricks, and make a wall. You can chop down trees, plant trees, break down walls, whatever.

Because its the only sane option of the above, I am of course mostly considering #1 so far. However, I wonder if someone has an approach I hadn't considered? :/ If the game didn't include a model of frequent changes, this would be a non-issue.

If you're going to be encountering constant changes from both players and developers, you are of course going to have overlapping interests. I'd suggest approaching it in this manner:
Have map creation be modular (on the developers end) If you created a cool awesome castle place, make it placeable anywhere on the map. On that same token, have existing maps be modular. If someone built a log cabin where you wanted your tower of doom to be, simply relocate that block of land, and inform the owner that some cosmic force combined with a series of conveniently placed earthquakes moved his log cabin forty yards that way -->.
Or you could take the "I'm a dick" approach and simply drop a meteor on his house before you drop the tower on the meteor hole. :)
#4 Apr 17 2009, 10:35 am
In response to Jeff8500 (#2)
Jeff8500 wrote:
The solution is simple: bring the game down occasionally to add small updates. I'm sure your players wouldn't mind a couple hours of downtime occasionally! If this is unsuitable, your smart map tool is probably the best idea that actually involves work.

This isn't about downtime. The game will have regular downtime, probably once a week for a few hours.

Developer checks out map, as of Monday the 15th. He works on the map for a week. Meanwhile, players and NPCs make changes to the map. The developer wants to check his edits back in, but they might conflict with the way the map actually looks now. He's going to try and upload a changed version of how the map was as of the 15th, which is the issue.
#5 Apr 17 2009, 12:00 pm
In response to Alathon (#4)
Alathon wrote:

Developer checks out map, as of Monday the 15th. He works on the map for a week. Meanwhile, players and NPCs make changes to the map. The developer wants to check his edits back in, but they might conflict with the way the map actually looks now. He's going to try and upload a changed version of how the map was as of the 15th, which is the issue.

I feel that this is the crux of the issue. The core problem seems to be that you want to allow developers to fine-tune and sculpt areas in broad strokes while also having the world itself modifying itself as it goes.

Honestly, the best way to handle this would be, as mentioned above, to update the maps during regular downtime. If the game will be down once a week, then push the updated maps once a week. Trying to do a concurrent system will break immersion in one way or another. If that doesn't bother you, then options #1 and #2 would be the best way to go, in my opinion.

I may have more later.
#6 Apr 17 2009, 12:58 pm
The idea I had after reading your post is incidentally similar to one of Loduwijk's ideas. It's partially based on the way graphical windowing systems keep track of painting the windows: flag certain regions as invalid.

If you consider that, at the time that the "test" database is checked out, all of the map is "valid" to be edited, then you can flag certain regions of the map as "invalid" when players make changes. Meanwhile, changes that the developer makes to the map might be flagged as well in a similar manner. The invalid regions might be marked, say, by coordinates (perhaps the coordinates of opposite corners of a rectangle) and be stored as entries into their respective databases. Perhaps when submitting multiple entries into the same database, you might even write an algorithm to combine invalid rectangles that overlap to keep the number of entries to a minimum.

When the developer tries to check-in the changes, you could run simple tests to find overlapping invalid rectangles between the two databases, and notify the developer of conflicts. The developer then might decide to "reset" the conflicting regions to what the players have generated (either to leave as-is or to expand upon via further editing) or to force the new changes to overwrite player developments.

Barring the idea of forcing all development to happen during server downtime, that seems to be the best solution to me. I very much dislike your option #1, #2 seems relatively close to this suggestion, and #3 makes me sad.
#7 Apr 17 2009, 1:40 pm
In response to Kuraudo (#6)
I find it striking that so many people consider #1 bad. #1 is valid for a number of reasons. The game is partially about resource conquest and territorial claim - Having an overland map would allow a much better realization of that, although it does risk breaking map atmosphere occasionally.

As for the thoughts so far:

Updating maps *only* during downtime is not feasible. editing would have to begin *and* end during downtime. Its just not possible.

The overlapping regions idea has merit, but its also not an option to block player gameplay when an area is being edited.

I've speculated some on things, and there are a few things I'm considering so far. One obvious consideration is to always only upload changed things - Never the whole map, unless specified. This prevents non-textures from changing when textures are changed, f.ex. Unless by changing the textures you invalidate something else.

Another notion is to clearly emphasize where players can build, and where NPC camps can bound up to - And keep the NPC camps out of 'pre-made' areas; so you have a world built up of spots for city building, road/areas in between which are mostly non-dense or left unchanged, inhabitable by NPC camps, and then pre-made areas with lots of detail that don't change except by developer hand.
#8 Apr 17 2009, 2:21 pm
In response to Alathon (#7)
Alathon wrote:
The overlapping regions idea has merit, but its also not an option to block player gameplay when an area is being edited.

The idea I proposed wouldn't block player gameplay. Rather, it would track gameplay, and compare what changed regions to later-edited regions, so that the editor could compensate before fully committing changes.
#9 Apr 17 2009, 5:49 pm
If they show up where players are do something creative. Such as have a group attack this settlement driving the occupiers out, then having the group act like their building what you edited in. Just add in the edited part and the group moves on acting like normal travlers.