 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Mindcrime told me it's Egyptian for "shit eater" or something. I dunno.
The number 69 was never used for a speedmap. I currently have the most awesome reference ever imagined which I will include in a secret area in the final version of the map. The chain maps I've played have usually turned out to be kind of arse because nobody thinks about anything more than their two rooms so you wind up with a map that's a bunch of short segments and suddenly it ends. The only exceptions were e1m1rmx, because it was just czg and vondur with a plan to follow, and the results of the SM39 (I think) debacle. Someone organized a speed chain map and promised to put the parts together into a whole map, and flaked out until RPG organized a contest to get them assembled. whoever that was.
So if you guys want to do a chain map, please approach it differently. Perhaps agree on a very very general plan (doesn't even have to be laid out, just a description of where the major key/door pairs and hubs are) first and let each mapper interpret his chunk as he goes while still following that guide? Perhaps a rotation where the first person roughs in a chunk, the second person details that while roughing in the chunk after it, and so on, so there's a little more overlap between mappers? The map gets passed three times
At first Everyone makes his three rooms At the secound round everyone can change all other rooms than his rooms. At the last round the mappers can only change their rooms and can make changes undone. At the and a "moderater" should have a quick look on gameplay and does changes if a mapper makes his rooms off-theme. time factor of such an approach would be more costly than if one mapper was to create a single map on their own.
I would suggest a small thematic episode would benefit from the approach you describe. Each mapper creates a speed map one evening, putting the effort in creating a complete layout with very limited detail and monster/game play set up. Each map gets passed to another mapper to fill out the details and whatnots. It could be passed to a third mapper whose sole purpose is to clean up the map and polish the elements established by the first two mappers. Once this process is complete, one overall ubermapper of the RPG sort, edits the maps to provide a linear continuity so the maps can be played as an advancing sequence. previous title reads:
The Problem The Creats Is it should read: Thumper is syntatically challenged or The Prroblem this Creates is in the Time factor invloved . . . take your pick. our chainmaps have been everybody creates a piece, then one person assembles them. This can lead to the problems Lunaran mentions, but on the other hand, if the person assembling them can work his magic, he could resolve those problems but making changes/adding new sections as needed.
The other possibility is a "pass-the-map" approach in which everyone has enough context to make good decisions. SM69 started as the first type, with RPG doing the assembly. Then it became the second type, with RPG and I passing it back and forth. And as headthump says, the time factor of passing it back and forth can mean the map takes YEARS to release. the map takes YEARS to release.
It is already the case for packs with simple rules (e.g Base Pack) so forget the idea, except if you have ages to waste.. Seriously, the concept is quite interesting, but I think it will be pain in the neck to put it in place, and to achieve such a "project" in a reasonnable time. You would need at least: - people that really commit to release on time, or at least in a given time, in order to not have ages of delay as you mentionned - strict rules about the theme (texture set choice, etc..) - strict rules about Well, I don't want to discourage enthusiast mappers to commit for this kind of "event", but I guess it will be really deceiving if nothing comes out at the end... refer to the sarcasm at the beginning of the post... :P In anyway, rules will be very important there, and also the respect of rules.... my 2 cents... ;) on an sm666 if I remember correctly. If not, Satan's Wang might be the right choice.
for the passaround method:
1. Add exactly two rooms, corridors etc don't count. 2. Provide no more than two exits, preferably just one. The exit must be some kind of door or corridor. 3. If you provide a second exit, it MUST be a key door. You may only do this if a) there's still a key left and b) you're not the starting mapper. 4. If previous mapper did provide a key door, your part MUST be a dead-end and contain a key. 5. If it turns out you're the last mapper, you must build an exit and compile and publish the map. The first mapper builds his part and starts a thread. People volunteer in that thread and they map in the order they volunteered. Transfer is by email. A mapper should pass on the map file after one week, in a compileable state with the exit sealed. Otherwise he must withdraw (he may re-volunteer later.) The texture set is knave (?) and Quoth is allowed. There are no game modes or skill settings, just single player. because my last project is very linear... at least at the beginning: you will have to suffer this before having "fun"....
A passing-on type chainmap will necessarily be linear. It is a linear process.
If you make no rules, somebody might build eight exits from his part, two of which are underwater, and the project would DIE at that point because not enough mappers are participating to seal all those exits. The rules I suggested already allow for branches to make it less linear than it would normally be. I agree with JPL that such a project would need relatively strict and simple rules to have a chance of completion. I happen to have a basic understanding of the way open source project development works, because I have been kind of involved there. So I tried my hand (brain) at a simple ruleset. In the open source community, it is typical that one person starts a project and then others pick it up, modify and improve it. It may not look like it, but there are actually very strict rules behind that simple process, some from the GPL and some from revision control systems like CVS and Subversion. Strict rules can make a project work better instead of complicating it. Linux is probably the most prominent example. As an experiment, let's outline what happens if you transfer the "linux model" to a Quake map: 1. You as a developer take somebody else's project, i.e. a map that is under the GPL (the rules.) If there is a maintainer, you either cooperate with him (wise) or you do a "fork" and become your own maintainer. 2. You improve it, make the changes you deem necessary, increase the version number and zip it up together with a readme, a copy of gnu.txt and the source code. You don't need any permission to do any of this. It's not theft. It's actually THE NORMAL WAY. It's the same as the passing-along chainmap model - you would just start with a complete map (for example one of the GPL Quake maps) and then it passes through many people's hands, everybody improves something and re-uploads it. Large (non-linear) projects work more like the traditional chainmaps; they need someone to bring order to chaos, so to speak. And that's what a maintainer does. He decides what goes in and what doesn't. He puts the pieces together. It's a social experiment, only successful as long as people are willing to give up control. Control-freakism (for "artistic" or commercial reasons) immediately kills the process. Even the maintainer is just a manager, not a control freak. If he is, there will typically be a fork, most developers will desert, and the old maintainer will be left in the dust. There are famous examples of this (Xfree86 to xorg was the last one.) I think it's desirable for Quake mappers to understand that model, so further development of the now GPL'ed maps is even possible. Right now, people are just using them as a scrapyard. That's primitive. Why not adopt one instead, improve it, give it a version number and declare yourself the maintainer. Then let people send you "patches" and just bump the version number. The Shub-Hub would be an ideal repository. I fail to see why this would be too complicated. It's super-easy in fact. Man, I haven't stumbled into this forum since roughly
Hope all is well with everyone. Could someone list all the q1dm maps that have come out in the last five years for me? JK. Cheers. q1dm maps that have appeared on the Func_board I'm afraid. You may find a half a dozen or so in the archive, some of them are pretty good.
Vondur has several great maps on his site http://vondur.net If you are handy with a bsp compiler and have the sources for Quake2 or Quake3 Arena maps (some mappers open source there content), converting them to Quake bsp is a pretty trivial task. If you need some bots and waypoints for newer maps check out the forum on inside3d.com. Get Gibbie's sexy maps!
Also maps by Zakaa: http://www.saunalahti.fi/zakaa/
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |