Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Impboy4

Updating the SLIGE Source Code

Recommended Posts

Just a question for whoever programs; Have any of you ever wanted to update the original SLIGE source code to be used in modern PC's now? I found the source code via using the Wayback Machine and David Chess had a To-Do list in the code file that listed bugs and possible upcoming features. You think anyone would step up and try to accomplish the list?

I like SLIGE because it makes layouts that are not confined to a rectanular area like OBLIGE does. I'd like to see SLIGE be able to make angle-forked layouts though.

Share this post


Link to post
Impboy4 said:

You think anyone would step up and try to accomplish the list?


Why don't you take it up as a personal, free-time project, as a "side quest" to e.g. learning to code? Otherwise, you could wait forever.

Share this post


Link to post

Hmmm, maybe I will make a port with a GUI, just for grins.

But I won't be doing any other enhancements, as I'd rather work on my own random level generator (Oblige).

Share this post


Link to post

Keep in mind that the SLIGE code is essentially one big, ugly hack. It might not be easy at all to continue where others left it, so the very first thing I'd do would be a refactoring and reorganization of structs etc. unless you enjoy working with a single gigantic (500K+) C source code file (last time I checked, it was just that). I know I don't.

IMO, it will end up in a Limbo just like XWE has: that too has had a "source code release" which however is missing important dependencies which one has to reconstruct before even attempting to build it just to see if it works. And, quite honestly, it's not the easiest code to understand (basically, anything written in Delphi sucks in terms of maintainability, IMO). SLIGE seems like more of the same.

On a related note, there's something that always puzzled me: the sceenshots posted on the "official" homepage of the project look much better than what is usually considered achievable with SLIGE, in particular this one:



I wonder whether the author actually edited/embellished the generated levels...or SLIGE is indeed capable of doing much better, but is a pain to properly configure (apparently, it's possible to define yout own themes in external configuration files, which ofc none does).

Share this post


Link to post

I'm kind of a SLIGE fan. :-) The maps it generates are often unremarkable, but occasionally you do get a gem or something that actually looks decent (BTW, those screenshots are entirely legit, I've seen it do even better stuff than that). Sometimes I even look to it for inspiration, because interesting results can sometimes come from randomness, whether it be strange architecture, texture usage, or whatever. Unfortunately, yes it only generates arthogonal designs, and just mixing up the angles a bit would probably improve it a lot.

Anyway, tonight I was just running through an episode, mindlessly shooting up some monsters and found that it had somehow generated a pretty tough but cool secret map. I had to warp there after finishing E1M8, because I missed the secret exit, so started with just the pistol. The map in question is pretty small, but populated entirely with cacos and lost souls. And although it has a chaingun, there's almost no ammo for it. The only weapons available are a rocket launcher (and ammo scattered around) and some berzerker packs. So the challenge becomes deciding when to tyson and when to (carefully) use rockets in some tight spaces, with lost souls darting all about... ;-)

If anybody wants to try their hand at it, here's how I generated that particular episode (using SLIGE version 490):

slige -levels 8 -seed 749512341
bsp slige.out
Actually I didn't use the -seed part, but you'll need to in order to generate the same exact PWAD. SLIGE saves the random seed it uses in the output file, so I just grabbed it with "strings slige.out | head" (and the seed is also present in the atual PWAD as well).

Oh and I never did try setting up a custom config. That might be interesting...

Share this post


Link to post
Maes said:

I wonder whether the author actually edited/embellished the generated levels...or SLIGE is indeed capable of doing much better, but is a pain to properly configure (apparently, it's possible to define yout own themes in external configuration files, which ofc none does).

I'm sure in the process of writing Slige he probably saw thousands of different levels, and had more than enough opportunity to pick out ones that looked nice as screenshots. We already know that Slige generates interesting and weird things on occasion.

Share this post


Link to post
andrewj said:

Hmmm, maybe I will make a port with a GUI, just for grins.

But I won't be doing any other enhancements, as I'd rather work on my own random level generator (Oblige).

Is that the SLURP thing you're working on? What does it stand for?

Share this post


Link to post
printz said:

Is that the SLURP thing you're working on? What does it stand for?

Yes. It doesn't stand for anything (like SLIGE doesn't stand for anything), just a silly sound name in the spirit of the original program.

Status: it is working, but making it properly installable and packaging it is a chore that I haven't felt like doing yet.

Share this post


Link to post

As someone who has spent some time with the SLIGE source code I can say that it really isn't worth the effort involved to update it. Like Maes suggests it really is one giant set of procedural algorithms. Separating it all out with OO design aspirations is not only a technical challenge but in fact a fools errand. I spent a couple of weeks doing just that as a learning exercise (nearly eight years ago in fact!), however at the end of it all I was deeply unsatisfied with the result.

As a consequence of that experience I learned a valuable lesson -- do not try to apply OO methodologies to what is inherently a cascade of procedural algorithms. Certainly OO can factor in a random map generator but it requires design discipline to do it well.

The problem with SLIGE on a technical level, however, is that the procedural logic is implemented in entirely the wrong language (i.e, C). Andrew Adjapted had the right idea with his Oblige project -- get the procedural "airy fairy" logic of map generation into an interpreted (i.e., scripting) language. The rest of it, the actual map element components and geometric primitives (vertexes, lines, sectors, etc...) could however remain native (and there are a lot of benefits to doing so, not the least of which being performance).

There are no magic formulae or such lurking in SLIGE so in my opinion it would be better to start over.

Share this post


Link to post

slige.c - just under 15,000 lines of pure ANSI C goodness. :-)

There may be another benefit to translating its algorithms to a scripting language... SLIGE gets crash-happy (segfault) when I tried to create a new custom config. Maybe my syntax was wrong, or I forgot to change something, but I only added a few dozen lines to create a new "GRAY" theme, and now it crashes 9/10 times without much indication of where the exact error lies. I guess debugging the coredump would be the next logical step, but it's kinda crazy to have to do that just because your config is off. ;-) Without any sanity checking in the config parser, it's almost like you need a front-end program just to generate a "valid" config file.

Share this post


Link to post

Seeing how SLIGE levels look and feel and having played dozens of levels from its generated WADs, I honestly would say it's not really worth editing.

You are better off editing the Obhack (V2 based) or the OBLIGE V3 codebase if you want to toy around with it as their code is easier to mess with as they are in multiple files, not one giant mess of a C file that SLIGE's is.

On "rectangular levels", I think you should know that V5 is still a WIP so you should not base the opinions on that but when it is a full release later in the year or early next year.

Share this post


Link to post
Mr. Chris said:

You are better off editing the Obhack (V2 based) or the OBLIGE V3 codebase if you want to toy around with it as their code is easier to mess with as they are in multiple files, not one giant mess of a C file that SLIGE's is.

Why did OBLIGE fork into two parts? What's the difference between them? Can't they join back?

Share this post


Link to post
printz said:

Why did OBLIGE fork into two parts? What's the difference between them? Can't they join back?


I don't know, maybe because the source code is freely available to modify under GNU(?)

Also V2 is an older version which had more rectangular architecture than V3 did as it was rewritten from the ground up.

Share this post


Link to post
Mr. Chris said:

I don't know, maybe because the source code is freely available to modify under GNU(?)

Yes, it's available under GNU. But did the separation happen because of different design styles or customizations that can't fit together?

Share this post


Link to post

I really like the fact SLIGE doesn't have any kind of GUI dependencies. The source code is probably salvageable, even if some people gave up trying to refactor it into OO code. Right now the biggest problem seems to be the difficulty in creating valid config files for new themes. The maps it generates are fine though. They're different enough from OBLIGE maps to be interesting in their own right.

Share this post


Link to post
printz said:

Why did OBLIGE fork into two parts? What's the difference between them? Can't they join back?

There is some info here: http://oblige.sf.net/doc_history.html
(nothing about V5 on there yet)

The fundamental design of each version is very different:

V2 worked with 64x64 blocks, which could be subdivided into 16x16 "fragments". Prefabs were specified in terms of these units, with ASCII strings. It used Lua code to convert that map representation into sectors/linedefs/etc. Rooms were a fixed size of 3x3 "seeds", each seed is 192x192 units, plus a 64 unit border between rooms where walls, doors and windows could go. (actually later on rooms could be "nudged" for other sizes)

V3 and later work with quake-like brushes, which are assembled together in a "CSG" process (in C++ code) to create the sectors/linedefs/etc. Rooms are always a rectangle, and there is no border between them, so walls and doors encroach into the space of a room. It did everything on a seed level (192x192 square), so doors (etc) were limited to that size. Everything in the level (walls, doors, switches, etc) was generated using Lua code which explicitly placed brushes (via function calls).

V4 moved the prefabs into Lua files with a data-driven method, definiting the brushes and entities in Lua tables. Also the overall map plan had "hallway channels", a 1 or 2 seed wide gap between room areas, used to place hallways. Rooms could now be non-rectangular shapes, like 'L' or 'T' shapes.

V5 moved the prefabs into WAD files instead of Lua files, and changed the seed size to 256x256 instead of 192x192. Currently room areas are fixed at 3x3 seeds (but rooms can consist of numerous room areas), and hallway channels are fixed at 1 seed wide. Rooms are often built using large (768x768) prefabs. Also the game definitions have been split apart into separate files, e.g. all the DOOM monsters are now defined in "x_doom/monsters.lua".

Share this post


Link to post
hex11 said:

I really like the fact SLIGE doesn't have any kind of GUI dependencies.


I've long wanted to do a "Random map of the day" doom server using OBLIGE levels, but you can't automatically generate maps because of the GUI.

Share this post


Link to post

I think at least one recent version of OBLIGE has a CLI option, but it still needs the FLTK libs to even build a binary. And when I tried, my OS only had older packaged version of that library, and the one OBLIGE needed wouldn't build cleanly from source. But a long time ago, I did make minor changes to a really old version (probably v0.97) so the Lua code could be run directly from the shell (just by pointing /usr/local/bin/lua at it). I don't have that diff anymore, but should be easy enough to re-create it...

I can also think of other situations where somebody would want to run the generator without a GUI: they might spend most of their time in framebuffer console, where SDL-based stuff runs fine, but X libs won't.

Share this post


Link to post
hex11 said:

The source code is probably salvageable, even if some people gave up trying to refactor it into OO code.


The very first step, before even going OO, would be to at least split it into multiple files, headers, structs and possibly group functions by functionality/purpose, so that at least it makes some sense, while keeping it ANSI C and compileable.

Then maybe we can start talking about OO or whatever.

Share this post


Link to post
AlexMax said:

I've long wanted to do a "Random map of the day" doom server using OBLIGE levels, but you can't automatically generate maps because of the GUI.

Can't people do that privately? Why deploy a server for it, other than 'just for fun'?

Share this post


Link to post
printz said:

Can't people do that privately? Why deploy a server for it, other than 'just for fun'?


A server?! That's like, so 90s, dude! The only Web 2.0 compliant way is obviously to compile SLIGE to Javascript using emscripten, and have it running entirely client side. Because, after all, the Browser is the platform nowadays.

Share this post


Link to post

I have to say that running SLIGE from a remote server just seems dumb. Particularly on the web. Why pay for the CPU time and bandwidth to transfer the wad to whoever wants it when you could instead just randomly pick a seed and tell users to enter it into SLIGE themselves. Or, why not simply serve SLIGE.exe or do something like Maes suggests with javascript. It would probably be cheaper to serve the executable than the wad file it generates.

Share this post


Link to post

Maybe the server spitting out the seed information for clients to use so they can join, something like that? Or would exact CRC keep people from joining? I think I had this issue doing co-op with an OBLIGE wad, I had to give him an exact copy with the time and date as well.

Share this post


Link to post
Mr. Chris said:

Maybe the server spitting out the seed information for clients to use so they can join, something like that? Or would exact CRC keep people from joining? I think I had this issue doing co-op with an OBLIGE wad, I had to give him an exact copy with the time and date as well.


That's probably because those tools don't build the nodes and REJECT maps themselves, AFAIK, so the seed of a map is not enough to generate a 100% CRC-exact WAD file. There is node building, REJECT map building and WAD repackaging to consider.

Even if you use exactly the same tools on two different machines, there might be differences due to e.g. different kind of junk in data structures which then get written to disk (e.g. contents of strings after null terminator), and if the node builder uses native floating point arithmetic at any point, then all bets are off: there might be outright different numerical results -ever so slightly- on different CPU architectures.

The only way to guarantee 100% CRC-exact WAD files is to also provide the node building and WAD packaging tools, explicitly initialize/clear memory structs, and use the same "safe and slow" floating point emulation on all platforms, if FP is really required.

Share this post


Link to post
printz said:

Can't people do that privately? Why deploy a server for it, other than 'just for fun'?


...Coop?

I mean, that's kind of why you host doom servers, to play with other people. :)

Share this post


Link to post
hex11 said:

I think at least one recent version of OBLIGE has a CLI option, but it still needs the FLTK libs to even build a binary. And when I tried, my OS only had older packaged version of that library, and the one OBLIGE needed wouldn't build cleanly from source.

Version 3.57 and later have a batch mode, "-b output.wad", which does not open the GUI. Settings can be set by command line arguments, e.g. "seed=123" or "game=doom2". This is the main way I run it myself.

V4 and later use a custom version of Lua, included in the source package, so there is no longer any issues with that library.

Removing the FLTK dependency would not be too hard, and I was about to suggest sending me a patch, but now is not a good time to attempt it because the Linux/Unix stuff will soon be transitioning to a proper installation system (i.e. stuff in /usr rather than just finding it from the current directory).

Share this post


Link to post

I tried searching the 'net for custom slige config files, but haven't found anything whatsoever except this really old thread about WolfenSlige, which apparently had a custom slige.cfg to generate Wolf3D-themed maps. Has anyone got a copy of this? The link on that page is dead, and archive.org doesn't have it either...

Also, on the subject of randomizers... I just round out the WARM node builder has a -rand option that randomly swaps things in a map. Only problem is, it doesn't leave the keys alone, so when I ran it on DOOM E1, E1M1 played fine, but problems started on E1M2 where there was no red key to be found. Examining the map in editor revealed that the key was nearby where the chainsaw usually rests, which of course makes the map unplayable since you have to go through the RK door to get there... This doesn't make much sense, unless perhaps this -rand option was meant only for deathmatch play? WARM also has a -dmit option to randomly place new items (from scratch, not just swap them around) for -deathmatch or -altdeath mode. That option also seems to completely eliminate nukage pools (they end up with a "dry" flat and also don't hurt if you walk there). Anyway, it's interesting stuff, just disappointing the item swapping is useless for SP mode. That should be easy enough to fix though.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×