Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 1
> They already use vertexes and chords (paths)
Really? Cool. It seems like there are a lot of file formats and structures and such that could be automagically "transformed" if you will into a DOOM map. Just need some scripting glue.
> Use groups of paths of different colors > to define different elevations
Cool, yup. So a stairwell would look like a little spectrum-ish sort of thing. Neat.
> There's just no way you can script > in all the detail
True, most maps will probably be pretty light on details, winding staircases, flicking light sources, and so forth.
> Noone would ever want to play > in your lame-ass uber-elite-hand-coded maps
Right, they won't be good for deathmatching. But they'll be good for a little demonstration, or for another way of visualizing a structure, or for... etc.
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 1
> Omgifol
Very nice! I notice that wad.py is only 21 KB. Interpreted languages are great, huh?
I'm looking through your WAD parsing code now... very helpful, thanks!
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 1
> Only THING, LINEDEFS, SIDEDEFS, VERTEXES, > and SECTORS.
Sweet. Thanks for the info. Right now I'm not that far along - mostly spending time understanding how Ruby's bit-packing methods work. But this is definitely helping.
> The rest are generated by the BSP builder
Cool. Yeah, I downloaded and compiles doombsp yesterday; it processes the few small WAD files that I have very quickly. I suppose I could wrap it with a Ruby d/l API... not sure how much benefit that would give over just invoking it as an external process, though.
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 1
> you dont have to build just the tree, but > other data like the REJECT and BLOCKMAP data > as well
Hm. So when generating a level, I have to fill in the following directory entries : THING, LINEDEFS, SIDEDEFS, VERTEXES, SEGS, SSECTORS, NODES, and SECTORS - is that right?
> just to generate a WAD without the data
Yup, that does seem to be the first goal to reach.
> as much as I love Ruby, it might be a bit > slow for this purpose
Probably for large maps, but for small maps it might not be too noticeable. Point well taken, though.
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 2, Insightful
> it might be a good application for a > genetic algorithm. You could evolve > the (near-)perfect level.
The difficult part might be coming up with a good fitness algorithm. I mean, a perfect level for one person may be a lousy level for another.
I'm hoping to come up with something that could be used to generate a level from, say, a building floor plan, or a Visio diagram of something - stuff like that. It would be nifty to run around inside of a Cougaar agent community, for example.
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 1
> SLIDGE
Nifty! I notice that Slidge requires that the generated map be run through a BSP calculator. Not a big deal, but maybe I can write/port one of those to Ruby, to make a all-in-one package. We'll see.
Re:Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 2, Interesting
> a scripting language for building Doom levels
Nifty! That should be helpful for figuring out how to write out the files, thanks much! I need a general purpose scripting API to Doom maps, so I'll keep plugging away on Ruby-DOOM. Thanks for the pointer, though.
Building a mod inside a level editor...
on
NYT on Game Mods
·
· Score: 4, Interesting
...is great and all, but it'd be nifty if a level could be built using a script. Like this:
I've poked around a bit trying to find a way to generate DOOM PWADs using a script... but I can't see a way to build a map outside a level editor. It seems like there are two components necessary - a sector layout thingy and a binary space partition calculator.
At any rate, I've started a little project to generate DOOM levels via a Ruby script. And if it turns out this is already possible via other means, I'll shut the project down:-)
Lots of familiar points are made - timezone differences impede voice communications, geography impedes physical communications, "fire and forget" projects are not very common, etc. Seems like it can be made to work, though, if folks on the project take the time to keep the communication lines open.
That sounds a lot like Markov chains and bigrams (or trigrams). Build a table of words, put together some "this follows that x% of the time", and off we go.
> Therefore, the changes that Microsoft will > make the the XML schema have a high liklihood > of being advantageous to Microsoft.
Right... that certainly makes sense. However, those changes are necessarily detrimental to anyone else. I mean, Microsoft keeps improving DirectX, and if I write a game, I benefit from their improvements. I guess I'm still not sure why this would be a bad thing.
> We're going to be plowing a field that > we don't own,
Right, we don't own the field, but at least we'll be able to look at it and add things to it via an public specification. Or something to that effect.
I guess one reason why I like this open spec is that I've been through the pain of reverse engineering extended MAPI symbols, and this public spec seems like a step away from that.
> They don't allow any modifications or > derivatives of the schema without permission
Hm. I guess I'm not sure what would be gained by doing that - i.e., changing the spec and republishing it. Why would that be a good thing to do, even if you could?
> Microsoft will be free to continue > changing their format with each new > release, breaking all the open source > programs for a time
Right... but couldn't the same be said of any API? I mean, if the Apache plugin API changes, I'll need to rewrite my mod_foo module to use the new API.
....seems like all you have to do is put a notice in the code about using the spec. Sounds kind of like the original BSD license - i.e., with the advertising clause.
Slashdot Mirror
> They already use vertexes and chords (paths)
Really? Cool. It seems like there are a lot of file formats and structures and such that could be automagically "transformed" if you will into a DOOM map. Just need some scripting glue.
> Use groups of paths of different colors
> to define different elevations
Cool, yup. So a stairwell would look like a little spectrum-ish sort of thing. Neat.
> There's just no way you can script
> in all the detail
True, most maps will probably be pretty light on details, winding staircases, flicking light sources, and so forth.
> Noone would ever want to play
> in your lame-ass uber-elite-hand-coded maps
Right, they won't be good for deathmatching. But they'll be good for a little demonstration, or for another way of visualizing a structure, or for... etc.
> Omgifol
Very nice! I notice that wad.py is only 21 KB. Interpreted languages are great, huh?
I'm looking through your WAD parsing code now... very helpful, thanks!
> Only THING, LINEDEFS, SIDEDEFS, VERTEXES,
> and SECTORS.
Sweet. Thanks for the info. Right now I'm not that far along - mostly spending time understanding how Ruby's bit-packing methods work. But this is definitely helping.
> The rest are generated by the BSP builder
Cool. Yeah, I downloaded and compiles doombsp yesterday; it processes the few small WAD files that I have very quickly. I suppose I could wrap it with a Ruby d/l API... not sure how much benefit that would give over just invoking it as an external process, though.
> you dont have to build just the tree, but
> other data like the REJECT and BLOCKMAP data
> as well
Hm. So when generating a level, I have to fill in the following directory entries : THING, LINEDEFS, SIDEDEFS, VERTEXES, SEGS, SSECTORS, NODES, and SECTORS - is that right?
> just to generate a WAD without the data
Yup, that does seem to be the first goal to reach.
> as much as I love Ruby, it might be a bit
> slow for this purpose
Probably for large maps, but for small maps it might not be too noticeable. Point well taken, though.
> it might be a good application for a
> genetic algorithm. You could evolve
> the (near-)perfect level.
The difficult part might be coming up with a good fitness algorithm. I mean, a perfect level for one person may be a lousy level for another.
I'm hoping to come up with something that could be used to generate a level from, say, a building floor plan, or a Visio diagram of something - stuff like that. It would be nifty to run around inside of a Cougaar agent community, for example.
> SLIDGE
Nifty! I notice that Slidge requires that the generated map be run through a BSP calculator. Not a big deal, but maybe I can write/port one of those to Ruby, to make a all-in-one package. We'll see.
> a scripting language for building Doom levels
Nifty! That should be helpful for figuring out how to write out the files, thanks much! I need a general purpose scripting API to Doom maps, so I'll keep plugging away on Ruby-DOOM. Thanks for the pointer, though.
I've poked around a bit trying to find a way to generate DOOM PWADs using a script... but I can't see a way to build a map outside a level editor. It seems like there are two components necessary - a sector layout thingy and a binary space partition calculator.
At any rate, I've started a little project to generate DOOM levels via a Ruby script. And if it turns out this is already possible via other means, I'll shut the project down
...is right here.
Lots of familiar points are made - timezone differences impede voice communications, geography impedes physical communications, "fire and forget" projects are not very common, etc. Seems like it can be made to work, though, if folks on the project take the time to keep the communication lines open.
> karma-lovin' CPD postsPopular stuff!
...as reported by CPD.
Here's the report.
That sounds a lot like Markov chains and bigrams (or trigrams). Build a table of words, put together some "this follows that x% of the time", and off we go.
Here's some Ruby code that implements a simple bigram model - it forms sentences using some quotes from C. S. Lewis as a corpus. It's based on examples from M. Tim Jones' excellent book AI Application Programming.
...at least, in terms of duplicated code clumps as reported by CPD.
Here's the report... not bad at all.
....for doing a PGP extension to Mailman.
The patch file alone is 56 KB... looks like they put in some effort on that one. Pretty cool.
> more efficient.
That'll make RubyForge (and other GForge installations) a bit faster, since GForge has a fair number of IN clauses:Looks like the survey and the searches should both benefit. Sweet.
> you can't be sure they'll continue in the future
Right, certainly. However, damning Microsoft now for things they might do in the future seems a bit harsh.
> documents can last hundreds or thousands of years
Right, but they can be converted from one format to another.
> they don't take into account the documents
> that will eventually be lost
Why? Just because Microsoft release v2.0 of the spec doesn't mean you can't keep your v1.0 reader around.
> It's not an open spec.
Right, but it's a public spec, which is at least a step in the right direction.
> Therefore, the changes that Microsoft will
> make the the XML schema have a high liklihood
> of being advantageous to Microsoft.
Right... that certainly makes sense. However, those changes are necessarily detrimental to anyone else. I mean, Microsoft keeps improving DirectX, and if I write a game, I benefit from their improvements. I guess I'm still not sure why this would be a bad thing.
> We're going to be plowing a field that
> we don't own,
Right, we don't own the field, but at least we'll be able to look at it and add things to it via an public specification. Or something to that effect.
I guess one reason why I like this open spec is that I've been through the pain of reverse engineering extended MAPI symbols, and this public spec seems like a step away from that.
> They don't allow any modifications or
> derivatives of the schema without permission
Hm. I guess I'm not sure what would be gained by doing that - i.e., changing the spec and republishing it. Why would that be a good thing to do, even if you could?
> Microsoft will be free to continue
> changing their format with each new
> release, breaking all the open source
> programs for a time
Right... but couldn't the same be said of any API? I mean, if the Apache plugin API changes, I'll need to rewrite my mod_foo module to use the new API.
....seems like all you have to do is put a notice in the code about using the spec. Sounds kind of like the original BSD license - i.e., with the advertising clause.
...called the Interoperability Prototype for Liberty.
Just to see what would turn up, I ran PMD over the source code - it came out pretty clean.
> There's also bindings to [...] Ruby
Yup, it's on RubyForge - WxRuby.
...see this post to TheServerSide. A lot of these look like common design patterns and standard Java/J2EE naming conventions.
You can also see Jim Jagielski's response to some questions here about this issue. Sounds pretty reasonable.
...with its product activation gibberish as described in this tale of woe.