Scripting and storing level generation

[eyenot]

I've been planning a roguelike for awhile and I feel like coding it, now.

One of the first thoughts I had was that all of the procedures for generating a level could be scripted. "Fill a square of random height and width with a certain terrain feature." "Pepper a random number of this sort of enemy at various distances from this location." "Build a random box out of wall tiles. Draw a path of dirt tiles between two random points using 1/2 drunken walk and replacing any stone walls encountered with doors." "Make a room between these two corners filled with maze algorithm #4." Etc.

This is interesting to me because it would allow me to script themed levels and to store those themes in files that are packaged with the game. This would allow me to keep the level generation out of the code and inside some files, instead.

For the sake of creating these scripts I've been thinking of coding a mapping program. It would allow you to select various procedures and to see them implemented in front of you. For example, to build an underground cave, you would start with a command to fill the level with solid rock. Then you would pick a random point and fill a circle of random radius with dirt floor. Drunken walk to another random point, digging out the rock the whole way, and blow up another circle. Etc. So as you do these things, the level appears in front of you step by step. When you save the level, you are actually just saving the specific script commands into a little file. You can re-run the script numerous times to see what kinds of levels could be generated and if any glitches come up.

I obsess with scripting a roguelike so much because if it can be managed, then you can mix elements of "fixed" RPGs like Dragon Quest or Final Fantasy with procedural generation. Things like drama could be scripted for the NPC's using the script language and stored in files.

This would also make expanding on the roguelike and player modification much easier.

This level scripting idea has obsessed me for quite some time. Since I'm going to implement this scripting and map making before starting in on the actual game, I'd like to solicit input from other roguelike designers.

What sort of things would you want to see in a level generation script like this?

What sort of versatility would you expect an app like this to provide? Should squares of map be able to carry an expandable amount of data, or is there a basic set of data (terrain type, elevation, object/s present or pile index reference, actors present, presence of traps or triggers) that is useful enough to assume?

Would you be able to generate all the levels you have in mind using a script like this and just a few registers, or would you need to be able to declare your own variables?

Would you rather something like this is stored in plain text and CSV, or as binary values?

[mushroom patch]

You may profit from having a look at how crawl handles vaults and more generally how it mixes and connects static content in vault files (which contain can contain lua code in addition to map data) with the usual roguelike map generation.

[eyenot]

You may profit from having a look at how crawl handles vaults and more generally how it mixes and connects static content in vault files (which contain can contain lua code in addition to map data) with the usual roguelike map generation.

I started worrying that I had posted this in the wrong heading (it seems almost like a programming question but I don't have any actual questions about implementing in code). So I took a look around there and found just a few similar posts. They don't seem to be asking the same things, though.

What's apparent to me is that many people report on engines they've already made, or languages they've already developed. But it just seems silly to me to rush in and make this scripting / level authoring thing without asking other developers what they would expect or want out of such a thing.

It would take a bit more work to implement, for example, the ability for the user to declare the grid's storage base, than to just assume a "universal" format for grids (actors, contents, terrain type, etc). It's not something I need -- all the roguelikes I've planned on paper (and either lost the notes or gave up for some reason) have had the same very basic grid properties.

I guess I'm asking for input because I have this fear that I'll think I made it sufficient for my needs but find out later I didn't. And if some developer had said, "yeah you should have added this feature to it, I would have thought of that first thing"...

It seems like such a simple task to make something like this but part of me nags and says "well if you don't make it sufficiently language-like it'll hit a wall" and the other part says "why implement a full language, that's stupid and completely counter-productive to the entire goal which is to just get as much content outside of the code itself as possible".

[Omnivore]

Making assumptions about what is necessary for future users is not a good idea imo.  Far too often I find libraries that while good, even great, at first glance, have so many hard-wired decisions in them that they are useless for anything beyond the simplest application.  For instance, try finding an A-star pathfinding implementation that allows for user supplied successor, move cost, and heuristic functions and allows for limitation of the number of iteration steps and in the event of not finding the goal, allows you to still get the best path it found before hitting the iteration limit.

Map generators are prone to these problems as well but at least in the map generator case, you can transform the output into the desired internal format.  As for the scripts that control the map generation process, *please* do not create yet another special purpose mini-language, I believe you'll find either Lua (preferably) or even Javascript suitable to the task.  Ideally the scripts would be able to pass a user defined data object for each generated cell along to the user implementation. 

If you're going to make a useful library, it should be expandable.  Third parties should be able to write an extension that adds a new tunneling algorithm, or a new cave generator, etc.  Ideally it would also be portable, written in C using a style that can be ported to Java, or wrapped in a .NET dll, or a <insert language here> FFI wrapper.

Of course, if you're doing it solely for your own use, then it is much easier, but I would still suggest making it a script driven rather than data driven generator along with having the ability to pass script defined data to the main program for each cell and designed in an extensible manner so you can add new generators easily.  If, for some reason, you are utterly opposed to using a script language, I would highly suggest using some form of formatted human readable text (JSON/YAML/XML) to drive it - even if you decide to add editing tools later, it'll be much easier to test and debug.

Finally, if you're going to create a library, I would highly recommend doing it as an open source project.  The more people involved in contributing, testing, and using the library, the more robust and useful it will, most likely, become.

[chooseusername]

Finally, if you're going to create a library, I would highly recommend doing it as an open source project.  The more people involved in contributing, testing, and using the library, the more robust and useful it will, most likely, become.

♫♫ Oh, what can it mean to a daydream believer ♫♫

It is questionable whether you will get any of these "more people".  Perhaps, once the project proves itself.  Perhaps not.  One thing you won't find is Omnivore giving monetary guarantees these people will turn up, or that they won't piss you around and waste your time and attention to the point you lose interest in the whole thing.

And if some do turn up?  More work for you.  People will contribute work and it will be buggy and flawed.  You will mention that the work is lacking and needs to be fixed, and the work will just sit there unfinished.  Then you'll spend time to finish that work and more often than not, you may as well have done it yourself from scratch to end up with something you'd otherwise be proud of.

And who supports the work contributed?  You do.  Someone contributes support for MacOS X and maybe some language.  Every person who encounters problems with shoddy work, or the bit rot that sets in as operating systems and installed packages change and vary, will likely complain to you.  You will be supporting compiling it with mingw, Visual Studio and so on if you want to get rid of this burden.  Or just ditch the code, and refuse to take any more unless other people are actively maintaining it.  *tumbleweed blows past*

It's easy to look at a successful project where this has all come together.  But there was likely many years on the road to that point, and lots of additional work you didn't want to be doing to get there.

When someone says if only you follow the true path and believe, you'll get 100 virgins in heaven, and you choose to believe - good luck!

[mushroom patch]

Yeah, you shouldn't release your code or a binary. Interweb service all the way.

[eyenot]

Yeah, you shouldn't release your code or a binary. Interweb service all the way.

Funny!

No, actually part of why I'm soliciting wisdom on this is because if I found it useful enough for myself to complete a roguelike with, then of course I'd just throw the source up and let somebody else compile it. I guess I could be convinced to offer a binary as well. Since whatever I do is just going to end up as a folder of .C files, though, it's not like it should be hard for other people to compile it.

It would be interesting to release a roguelike as a web app, though. At that point I would have to fulfill the point of having it on teh web, and make it a procedurally generated MMORPG. That sounds actually kind of silly and unfun from a purely RL perspective, though, so I'll probably avoid your suggestion. Thanks tho!

[eyenot]

Making assumptions about what is necessary for future users is not a good idea imo. 

This was all really sage advice. I kind of want to avoid making another library for the same reasons that I'm not really interested in using anybody else's library, and you already hit those on the head.

Well, in the end it doesn't even matter. <-- can't believe I typed that. The more I outlined and flowcharted and looked at it, the more it was apparent I was verging into "engine" territory. I had already given up the idea of keeping the toolkit and the game binary separate, and decided it would be easier to just play the game from inside the toolkit.

I guess what it comes down to is that the tool I really want isn't a library or a language but just a toolkit that I can use to make my roguelike really quickly. Of course there will end up being a "mini language", but the point would be nobody is expected to write in it except the toolkit, or read it except the toolkit. If somebody felt like modding a game they could dive into the plaintext and attempt it that way but why when the game is also the toolkit? So, that's the philosophy I'm using now.

So basically I'm working on something a la "rpg maker" and that sort of crap, but hopefully with nicely implemented branching story structures and procedurally generated content where needed.

I mean, if I had a nice fully scriptable text editor (I think Semware Editor may have been more or less fully scriptable) I would program a roguelike in that instead. Why remake an engine if there's no need for it? Another really nicely scriptable program was {c0mm0} modem terminal program. If {c0mm0} didn't have to be run in a DOSbox I'd even give that a crack, I used to really enjoy programming in {c0mm0}.

Right now my big hurdle is whether I believe a sufficiently fun, complex world can be handled in a fully linear fashion or if I will need to implement a stack for branching structure. So far (please don't ask for code or binary, I'm working with outlines and flow charts, here) I have the instruction pointer in complete free-fall more or less. An actor, or a grid trigger, or the keybindings, or a timed event can execute a script that can completely change the makeup of all of the above. So either I'll have to make a game-based assumption on where the next instruction comes from when a script ends (move to the next actor, hand control to user input, etc.) or else I'll have to implement a stack and *yawn* it just gets more language-like from there.

Implementing registers, jumps, a stack? ... Eventually it will probably be somewhat similar to Assembly but it will only serve the narrow purpose of letting a lazy person like myself make a procedurally generated, branching story line game "just in time". I have no way of keeping the game maker from doing something silly like pointing two actors at each other as references and creating a loop but oh well.

I'm having fun, that's what counts to me. If I end up making a behemoth that nobody besides myself will ever use, maybe that's even better! No need for "support"!

I basically just don't see myself finishing my currently planned roguelike without something like this.

[eyenot]

Of course I was avoiding "this is an engine" at first because there are already a bajillion engines in the world. Why make another engine when somebody else's probably does what you want?

So, who knows if this idea of mine will ever graduate from paper to code. It looks like 90% of what I want is already implemented in T-Engine (ToME). I will be playing with that for awhile to see if that can get done what I want to get done.

Thanks to everybody who responded.