Messages

1

Design / Re: Scripting and storing level generation

« on: February 08, 2015, 06:31:29 PM »

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.

2

Design / Re: Scripting and storing level generation

« on: February 08, 2015, 06:20:18 PM »

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.

3

Design / Re: Scripting and storing level generation

« on: February 08, 2015, 05:53:20 PM »

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!

4

Design / Re: Scripting and storing level generation

« on: February 06, 2015, 11:46:59 PM »

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".

5

Design / Scripting and storing level generation

« on: February 06, 2015, 10:28:57 PM »

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?