User made maps

G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

I've been playing N lately
(http://www.harveycartel.org/metanet/downloads.html), which is a great
time killer at work, and an excellent freeware platformer. Despite the
fact that the game is absolutely massive (~500 levels), it also has a
built-in map editor, and an easy way of obtaining user made maps. The
game hasn't been out for that long, and already a huge number of
incredibly creative and diverse maps have flooded the user made map archive.

Observing this phenomenon, so prevalent in other games such as Starcraft
and Doom, I think it's apparent that A) user made maps greatly extend
the lifetime of a game, and B) map makers will always find ways to
create maps that push the limits of the system above and beyond.

This same approach could potentially be used in a roguelike, with
interesting possibilities. If the developer creates a somewhat simple
to use map maker, makes it easy for users to load and play new maps, and
creates (or encourages someone else to create) a central repository for
user made maps, I think even a mediocre RL could find itself with a much
larger user base, and a greatly extended replay value.

Possibilities that I can forsee for RL maps:

1) Story driven maps. The mapper creates a small-to-large collection of
levels, with the purpose of telling a story. Obviously, strongly
plot-based, and probably won't push the limits of the system a great deal.

2) TC maps. Total Conversion maps, which hit it big with Doom, turn the
game into a whole new game (sort of). Whether the mapper wants to
create a Pacman level, recreate Hogwarts, or painstakingly recreate the
original Doom levels, it's all fun, very impressive, and massively popular.

3) Puzzle maps. Maps that put the player in a certain situation, with a
particular puzzle to be solved to beat the level. Whether it's
something bland and obvious ("oh, use the water wand to rust the iron
golem that's blocking the exit"), or more creative mind-bending puzzles,
these should be really easy to make with even the most basic mapping
utility, since the RL genre is so well suited to this type of gameplay
already. These could also be the RL equivalent of chess puzzles, where
you must "find the solution" within X turns, given a predefined setup.

4) Genre-bending maps. Maps that attempt to simulate another genre.
Given the (usually) turn-based nature of roguelikes, there are obvious
limitations to this one. However, strategy game maps are possible, as
are more traditional RPG style ones.

5) Oddball miscellaneous maps. The usual odd assortment of maps that
creative players come up with. Everything from defense maps (defend
self or target from increasing hordes), tower defense maps (prevent
non-attacking enemies from escaping past you and reaching their
destination), madness maps (uh, kill *lots* of stuff), and whatever
wierd things mappers can come up with.


Now, obviously, not every RL should have a map editor. However, it'd be
rather nice to see a few such RLs get released. Obviuos prerequisites
for any RL to pull this off: A) an at least somewhat capable scripting
system, B) the ability to edit monster names/stats/abilities/etc through
the map file, and C) the ability to load and play maps through an ingame
interface, that does not cause permanent changes to the game's main
files (i.e. changing "goblins" to "gobbledy-beloved patriot" in a map should not
cause the change to be permanent in the actual game.).

Keep in mind, I'm talking about actual map editing, *not* mod making or
RL engines or anything else. Creating a game with an engine is a far
different experience from throwing together a Dig Dug map.

But, yeah, just my $.02.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

At Wed, 07 Sep 2005 02:59:31 -0500,
Timothy Pruett wrote:

> Keep in mind, I'm talking about actual map editing, *not* mod making or
> RL engines or anything else. Creating a game with an engine is a far
> different experience from throwing together a Dig Dug map.

Well, you can take any of the sample H-World maps and edit it (it's
a plain text file) to create other maps.

--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
. . . ..v.vVvVVvVvv.v.. .
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Radomir 'The Sheep' Dopieralski wrote:
> At Wed, 07 Sep 2005 02:59:31 -0500,
> Timothy Pruett wrote:
>
>
>>Keep in mind, I'm talking about actual map editing, *not* mod making or
>>RL engines or anything else. Creating a game with an engine is a far
>>different experience from throwing together a Dig Dug map.
>
>
> Well, you can take any of the sample H-World maps and edit it (it's
> a plain text file) to create other maps.

I never had a chance to toy around with H-World too much. It uses Lua
for scripting, right? If so, that's one more reason I need to download
it while I'm at work.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Yeah, I've been kicking a similar idea around for a while.

The fun of RL games is in discovering new stuff, and user-made content is a
great way to supply that stuff. One of my more distant goals for Witherwyn
is to have editors (for monsters, items, sections of dungeon, ect) built
right into the game and provide the facility, in game, to upload new modules
of content to a central server. This content could then be DLed by other
clients by Witherwyn itself. Every time you played, you would find something
new.

This idea has some serious obstacles (and I have some partial solutions)

* The game engine would need to be very flexible
* You would have to have a good way to validate the quality of incoming user
content
* You would have to make sure that the system was secure (scripts would have
to run in a sandbox of some kind, seems to me)
* Perferrably, the content would be catagorized in different ways, so the
user could check off the types of new content he wouldn't mind seeing in his
games.

I started thinking about these things after hearing Will Wright talk about
the content problem in open-ended games and how required content scales
superlinearly to the length of an open-ended game (vs. a game that plays "on
rails").

So, in short, I agree with you. Furthermore, I think the content
distribution system should be built into the client (and possibly
transparent to the user).

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Shedletsky wrote:
> Yeah, I've been kicking a similar idea around for a while.
>
> The fun of RL games is in discovering new stuff, and user-made content is a
> great way to supply that stuff. One of my more distant goals for Witherwyn
> is to have editors (for monsters, items, sections of dungeon, ect) built
> right into the game and provide the facility, in game, to upload new modules
> of content to a central server. This content could then be DLed by other
> clients by Witherwyn itself. Every time you played, you would find something
> new.
>
SNIP
>
> So, in short, I agree with you. Furthermore, I think the content
> distribution system should be built into the client (and possibly
> transparent to the user).

I agree with you here; I would like my game to have user made worlds,
incorporated in a semi transparent way to the user. I am basically
talking about content here (only data, no scripts), as a mean of
extending the game in terms of locations but not functionality.

However I see the need of a centralized depot for user made maps to be
reviewed by a competent team; the game could then automatically login
and download the approved worlds, incorporating them transparently into
the game.

>
> --
> Blog:
> Shedletsky's Bits: A Random Walk Through Manifold Space
> http://www.stanford.edu/~jjshed/blog

--
Slash
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Radomir 'The Sheep' Dopieralski <thesheep@ sheep.prv.pl> writes:

> At Wed, 7 Sep 2005 12:35:27 -0400,
> Shedletsky wrote:
>
>> * You would have to have a good way to validate the quality of incoming user
>> content
> There's one good way. Sit down and playtest it with all the combinations
> of already existing content. I don't have to say it's practically
> impossible.

You could divide the work. Provide a means for players who have downloaded and
played a particular module to rate it, and maybe even comment on it. Obviously
you'd also need a way for players to review the ratings and comments for a mod
before downloading it.

>> * You would have to make sure that the system was secure (scripts would have
>> to run in a sandbox of some kind, seems to me)
> They do. That's why they are called scripts.

One fairly obvious security path is to simply don't give scripts a means to
arbitrarily communicate with the outside world. If they can't read or write
files, establish network connections, or start external programs, there's
little or no room for them to compromise security.

At the very least, validate any and all data that leaves the sandbox. For
example, if scripts are allowed to access files at all, you should prepend
a fixed path to any and all file names passed from scripts. That will keep
the scripts in their sandbox instead of allowing them free reign over the
whole HD.

When filtering data, it's best to take a pessimistic approach. Instead of
looking for things to reject, assume that *everything* is to be rejected by
default, and then look for known-good things to allow.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

At Wed, 7 Sep 2005 12:35:27 -0400,
Shedletsky wrote:

> Yeah, I've been kicking a similar idea around for a while.
>
> The fun of RL games is in discovering new stuff, and user-made content is a
> great way to supply that stuff. One of my more distant goals for Witherwyn
> is to have editors (for monsters, items, sections of dungeon, ect) built
> right into the game and provide the facility, in game, to upload new modules
> of content to a central server. This content could then be DLed by other
> clients by Witherwyn itself. Every time you played, you would find something
> new.
>
> This idea has some serious obstacles (and I have some partial solutions)
>
> * The game engine would need to be very flexible
Not necessarily, really.

> * You would have to have a good way to validate the quality of incoming user
> content
There's one good way. Sit down and playtest it with all the combinations
of already existing content. I don't have to say it's practically
impossible.

> * You would have to make sure that the system was secure (scripts would have
> to run in a sandbox of some kind, seems to me)
They do. That's why they are called scripts.

> * Perferrably, the content would be catagorized in different ways, so the
> user could check off the types of new content he wouldn't mind seeing in his
> games.
You'd probably need a much more sophisticated filter, including, but not
limited to, black/white-list of users.

> I started thinking about these things after hearing Will Wright talk about
> the content problem in open-ended games and how required content scales
> superlinearly to the length of an open-ended game (vs. a game that plays "on
> rails").

In roguelike you usually deal with the problem by using combinations of
predefined parts, which grow in number exponentially to the number of
parts.

--
Radomir `The Sheep' Dopieralski @**@_
(Uu) 3 Sigh!
. . . ..v.vVvVVvVvv.v.. .
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

On Wed, 07 Sep 2005 02:59:31 -0500, Timothy Pruett
<drakalor.tourist@gmail.com> wrote:

>Now, obviously, not every RL should have a map editor. However, it'd be
>rather nice to see a few such RLs get released. Obviuos prerequisites
>for any RL to pull this off: A) an at least somewhat capable scripting
>system, B) the ability to edit monster names/stats/abilities/etc through
>the map file, and C) the ability to load and play maps through an ingame
>interface, that does not cause permanent changes to the game's main
>files (i.e. changing "goblins" to "gobbledy-beloved patriot" in a map should not
>cause the change to be permanent in the actual game.).

You forget the most important thing. D) Embed this editor in a highly
popular game. A successful game engine is the engine of a successful
game. Until you have a strong player base that wants "more like this",
your wonder engine will sit idle.

>Keep in mind, I'm talking about actual map editing, *not* mod making or
>RL engines or anything else.

You're just talking about a different aspect of the engine being
editable -- but you are talking about more than map editing when you
talk about changing monsters and scripting. In any case, the above point
applies even more strongly if your engine is less flexible and all you
promise is "you can make maps".

>Creating a game with an engine is a far
>different experience from throwing together a Dig Dug map.

Creating a game from an engine that's likely to be see the light of day
is as large or as small an exercise as you choose to make it. You can
take the example game and change the names of the uniques to the names
of your old girlfriends/bosses/gang rivals or whomever else you bear a
grudge against, add a few appropriate messages and (if graphical) change
the graphic tiles and you've created a new game, albeit one that's a
variant so minor probably nobody else would be interested. Or you can
tear the engine down to basics, use the existing game(s) only as guides
of ways to do things, and set yourself a task little different from
building a game from scratch.

--
R. Dan Henry = danhenry@inreach.com
 

Thomas

Distinguished
Jun 27, 2003
449
0
18,780
Archived from groups: rec.games.roguelike.development (More info?)

I think this is a great idea. I hope to eventually add this capability
to CHAZM along with some scripting and mod making that would allow a
user to customize any part of my game. This is lifetimes away though
now....

*I think that a simple environment could be created as an editor to
facilitate the creation of user maps.

-Thomas
RL: CHAZM
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Sherm Pendley wrote:
[...]
> One fairly obvious security path is to simply don't give scripts a means to
> arbitrarily communicate with the outside world. If they can't read or write
> files, establish network connections, or start external programs, there's
> little or no room for them to compromise security.
>
> At the very least, validate any and all data that leaves the sandbox. For
> example, if scripts are allowed to access files at all, you should prepend
> a fixed path to any and all file names passed from scripts. That will keep
> the scripts in their sandbox instead of allowing them free reign over the
> whole HD.

Prepending a fixed path to file names is not enough, current file
systems and operating systems offer many other options: relative paths
(../../../usr/local/bin/something), hidden streams (ntfs)
(innocent.txt:fortyGbOfInvisibleDoS), special writable devices
(/dev/hd0), network access (\\192.168.0.1\windows\something), other
exploitable features and the ever-present threat of exploits from
carefully "malformed" strings.
Ensuring that a file path is harmless is a nontrivial task, probably
best approached with clever regular expressions and a strict definition
of the sandbox; for a game mod it's probably best to avoid actual file
access and use logical resource names instead ("use 32x32 PNG sprite
goblin_b for this monster", "open this mod's high score file for
appending").
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

gatti@dsdata.it writes:

> Ensuring that a file path is harmless is a nontrivial task, probably
> best approached with clever regular expressions

I've been writing Perl for ten years. Clever regexes aren't a problem - I
can write them in my sleep. :)

> and a strict definition
> of the sandbox; for a game mod it's probably best to avoid actual file
> access and use logical resource names instead

That's more or less what I was getting at - the scripting engine wouldn't
take paths at all, just file names. It wouldn't even take a very clever regex,
just a simple one - if the file name matches "^[[:alnum:]\.]+$", prepend a
directory name and allow access.

Note that the pessimist principle applies to this pattern. It rejects by
default, and accept only if all-good characters are found.

*What* directory name to prepend would depend on context, so there's no need
for the module author to suppply it. If you're looking for a sprite or tile
graphic, look in the current module's "sprites/" directory for it. If you're
saving a game, choose the appropriate directory for that. Etc.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

> > However I see the need of a centralized depot for user made maps to be
> > reviewed by a competent team; the game could then automatically login
> > and download the approved worlds, incorporating them transparently into
> > the game.
>
> I tend to agree. If you let people do what ever they want there will always
> be some kid who uploads his "Magic Sword of DOOOOM +10000" or other cheap
> content. It might be that with a peer-review system that the community could
> be self-policing, kind of like WikiPedia.

Note that even automated systems might reject things. Giving that sword
to a beggar for example. Any shop routine can calculate the value of
that item and thus give it an appropriate danger level to retrieve it.
Which would then force a certain dungeon level or mob level.
You might even disallow items that reach a certain cost ( like this one
).

T.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

> I agree with you here; I would like my game to have user made worlds,
> incorporated in a semi transparent way to the user. I am basically
> talking about content here (only data, no scripts), as a mean of
> extending the game in terms of locations but not functionality.

Well this is where the extensibility requirement for the engine would come
in. There's only so many interesting things one can do by filling out a
spreadsheet of new monster/item stats. To create an active modder community,
I think you need the ability to generate new spells/NPCs/triggers/ect... The
Warcraft III engine is a good demonstration of this level of flexibility.

> However I see the need of a centralized depot for user made maps to be
> reviewed by a competent team; the game could then automatically login
> and download the approved worlds, incorporating them transparently into
> the game.

I tend to agree. If you let people do what ever they want there will always
be some kid who uploads his "Magic Sword of DOOOOM +10000" or other cheap
content. It might be that with a peer-review system that the community could
be self-policing, kind of like WikiPedia.

I think transparently streaming in suitable community content a pretty hard
problem, though. I can't think of one commercial game that does it. It would
be an interesting experiment -- but I don't have any illusions of doing
something like this anytime soon.

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

konijn_ wrote:
> > > However I see the need of a centralized depot for user made maps to be
> > > reviewed by a competent team; the game could then automatically login
> > > and download the approved worlds, incorporating them transparently into
> > > the game.
> >
> > I tend to agree. If you let people do what ever they want there will always
> > be some kid who uploads his "Magic Sword of DOOOOM +10000" or other cheap
> > content. It might be that with a peer-review system that the community could
> > be self-policing, kind of like WikiPedia.
>
> Note that even automated systems might reject things. Giving that sword
> to a beggar for example. Any shop routine can calculate the value of
> that item and thus give it an appropriate danger level to retrieve it.
> Which would then force a certain dungeon level or mob level.
> You might even disallow items that reach a certain cost ( like this one
> ).

Automated systems are the worst of all evils in such a system.

If one is trying to build a stand alone mod, something out of balance
in that mod may not be out of balance in another mod. I remember being
frustrated by the Neverwinter Nights engine which refused to let me
create a sword of dragon slaying because the CLevel would have been too
great. The fact that there was only one dragon in said module, and the
point of the module was to retrieve the magic sword to slay the dragon,
was irrelevant.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

Shedletsky wrote:
> > I agree with you here; I would like my game to have user made worlds,
> > incorporated in a semi transparent way to the user. I am basically
> > talking about content here (only data, no scripts), as a mean of
> > extending the game in terms of locations but not functionality.
>
> Well this is where the extensibility requirement for the engine would come
> in. There's only so many interesting things one can do by filling out a
> spreadsheet of new monster/item stats. To create an active modder community,
> I think you need the ability to generate new spells/NPCs/triggers/ect... The
> Warcraft III engine is a good demonstration of this level of flexibility.

You don't need extensibility. What you need is a popular game.

There already are excellent, fully extensible, roguelike systems.
H-World comes to mind as a system that would let you generate content
easily.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

I agree ,

'if one is trying to build a standalone mod',
otherwise an automated system is not a bad thing.

T.