Are you planning to upload some content to Quadropolis - Great! Read on!
The Cube Wiki article Distributing Maps contains the original text of this guide;
This deals with the specifics of Quadropolis postings.
It tries to prepare you for providing poished content to the community and avoid any unwanted tags, maybe even get you a starred content one. ;-)
I just want to share some knowledge and give some tips on mapping. This is for novice mappers as well as for people that are already familiar with Cube editing. For learning the basics of how to edit maps, refer to the readme.html.
Some opinions on certain topics might be influenced by my personal taste and views. I don´t claim this were the ways to do it, but it´s the way I do it and what I find important.
Since I have never made a singleplayer map (I like multiplayer better) I can only talk about making multiplayer maps here.
I will divide this into sections, which are
3. Design (detail, mapmodels, light and stuff)
Starting a new map, it is always good to have some basic concept or idea in mind.
In common terms, the flow of a map is describing how a map feels while navigating through it. Some cases which effect the flow are:
When a map has no flow, it means most of the times that it lacks some of the criteria which is listed in the next couple of aligns. Keep in mind that when you ignore some of the criteria, you may risk some serious flow issues on your map.
In common terms, gamemode entities are entities which are required for only certain gamemodes. Certain of those entities are:
Any other entities which affect the core gameplay are not considered as gamemode entities as the objective of the gamemode can be achieved without them as well or they can't be modified in the mapping process.
The base entity only appears activated in the modes Capture, Regen Capture and Hold (plus it's variants).
As the developer of the Open Source first-person-shooter project, Red Eclipse, I have come across many different types of personalities; some are good, some are bad. Quite often, I will have someone looking to contribute to the project who is so convinced that their point of view is so important that it only ever ends badly. Unfortunately, you can’t control this kind of thing, but in the past I have attempted to guide these people along the right path, albeit unsuccessfully most of the time.
I believe there is a misconception surrounding the phrase “Open Source”, that many people bang against and wonder why they’re met with such hostility. When a person decides to release their creations with an Open Source license, their desire is most often always to share it with the public in many ways, including allowing everyone to use and/or modify it for free.
You’ve probably heard the expression, “Free as in beer, not free as in speech”, but maybe don’t quite understand the implications of that. The creator of Open Source content is looking to give you something for free, and quite often allows you to take it and do whatever you want with it; the most beneficial part of which is the ability to study, modify, and play with it. This creator already has their own ideas, their own opinions, and their own way of doing things.
Every so often, you have an individual come along who has their own ideas and opinions, and they are so fixed on the concept that their way is the right way, they end up having a complete disregard for the creator, and the community behind that creation, if one exists. These people will enter a community, demand that everyone conforms to their vision, and when they discover the creator and/or community are resistant to it, blames everyone else for the fact that they failed. This often ends with the person declaring something along the lines of: “I should have known better, you don’t appreciate me, I’ll go elsewhere and get my way there.”
The problem is, these people don’t ever try to integrate with a project naturally, they appear to expect instant results as soon as they come along, and assume they know everything they need to know. This is mostly untrue. Throwing a tantrum and refusing to share your toys is the best way to ensure that everyone will instantly dislike you. To them, they were doing just fine before you came along trying to shake the tree and making demands of them, and they will continue to do just fine without you.
Open Source is a democracy of one. Someone, somewhere up the chain, came up with the idea and executed it. They built it, and they own it. Just because they have given something to you free of charge, does not entitle you to start telling them how to do their “job”. You’re not paying them, in fact, they’re giving up their free time to follow an idea that they are passionate about, and it is just a side effect of generosity that they released it for everyone to enjoy. Too many people think that Open Source bestows a right of ownership on them, but if you ever read one of these licenses carefully, all a creator is giving you is the right to use, distribute, and/or modify it.
So, if you’re looking to contribute to an Open Source project, now or sometime in the future, try to remember this: You are a guest in someone else’s home, please respect them and the work they have done. Try to understand their vision and their rules, get to know the way they operate, find out if they’re even interested in your ideas. If you approach them with a good understanding of their work, you’re more likely to get the result you are after, or maybe even find some other way you can fit in.
I found this most helpful, and haven't seen him explain it this well before and didn't want it to get lost in the comments of node/3184 'Why's there fewer starred submissions these days?', so I politely quote it here.
eihrul | 2011-10-15 01:40
The problem is that the mapping community is shooting itself in the foot. Quadropolis built mappers from the ground up, but now tries to operate at a level of sophistication that does not allow mappers to get feedback and grow. As has been said, new mappers are shoved away when they want community and feedback. Its standards are too high and simultaneously the wrong standards. I have a rough set of standards which I apply to maps for inclusion, which are really a balance of many aspects. If you only focus on one of the aspects, to the neglect of another one, the map is unlikely to get included. If you do a passable attempt at all of them, the map is likely to get included, even if it is not amazing. The bar is not amazing, the bar is balance. They are:
1) Performance. If the map is 400K verts because you spammed lots of little details everywhere, it is probably not getting included. 200K is more or less a sane top-end for big Hallo-sized maps. Spamming lots of water planes is almost always a no-no, especially in combination with spamming lots of geometry, since they multipled eachother. Try to stick to at most 1 water-plane in view at any one time.
2) Texturing. Texturing matters not just for appearance, but so the player can actually see where the hell they are going. I'm not trying to single anyone out, but if I am handed a map with very complex flow, and all hallways look the same because it's one solid gray mass or a such a noisy mass of random textures that I can't remember a pattern to them as I am running by, then the flow of the map has become more theoretical than actual. And, well, neither looks nice either. I may as well be running through a dark and twisty maze only to be eaten by a grue. :)
3) Lighting. The comments for texturing above apply to lighting, though with some slight difference. Too much noisy lighting with lots of different technicolor lights or almost-moire-pattern shadows from competing lights can make it hard to see and it just looks ugly. Even a simple sunlight with some skylight with some occasional accent lighting can be good enough for a lot of maps. Most people just try too hard here.
3) Geometry. I am actually rather forgiving of blocky detail, and people tend to overfocus on geometric detail to a fault. Spamming lots of noisy detail really tends to make maps look worse in general, and actually detracts from nice texturing and lighting, especially the texturing. You need to work with the cubes, not against them. Large details tend to work better than small ones, especially because at the pace people run around in Sauer your small detailing will mostly be ignored as people run by like cheetahs. Let the textures do the small detail.
4) Particles. Don't spam them. Sometimes particle spam can work in the right context, but usually it just looks a bit lame. It's not a deal breaker, but never the less, lame.
5) Mapmodels. Same caveats as spamming lots of small geometry detail.
6) Flow. Cramped tunnel systems or cramped hallways are bad. Too much verticality is bad. Too many teleports is bad. Too many jumppads are bad. Too open is bad (especially in CTF and capture), less so for FFA. Too many twists and turns is bad. The most popular FFA layout in Sauer seems to remain a hole with a ledge around it (complex). I think people overthink this one a lot as well.
7) Items. I think common sense mostly reins here, and that it is rare for people to really screw this up badly. Make sure items are available at appropriate frequencies according to their benefits. It is perfectly okay to omit the quad and health boosts and yellow armour in a map if you don't like their effect on gameplay for your map too, but generally all other items should be present. Quads/health boost/yellow armour very rare. Green armour kinda rare. Rockets/chaingun should be used judiciously. Shotgun/rifle/grenades a bit more available than rockets/chaingun. Health to taste. Pistol cartridges should only be placed only to insult/spite the player, but are not terribly useful.
8) Clipping. Usually I end up going in and fixing this myself on almost all included maps, but people never clip their maps adequately, so that the poor baby kittens escape and fall off the map and die. Save the kittens.
9) File size. The Sauerbraten download size is already big. Many people still have shit connections, and even if they don't, a huge download makes it less likely for impulse downloaders to try out the game because it will still take a long time to download. I don't care if you think otherwise. The download is not increasing 20MB for an FFA map, and even 5MB will make me skeptical. For 5MB, your map must be pure unadulterated awesome-sauce, like, better than almost every other map in the game. Smaller file size maps that are less a hindrance on the total package size are more likely to be included.
So - we saw handy do these in his mini_arena
and then explaining their creation in a tutorial included in factory..
also SheeEttin gave a very quick how-to in his comment to the mini_arena-node.
I've decided to put this up as a real guide too though - credits do have to go to those two for the research though! Well done boys - that's the true spirit of this community!!
Today, I have release Version 1.0 of my Sauerbraten editing cheat sheet. You can download it from my site, or here on Quadropolis.
The cheat sheet's aim is to give both new and experienced developers a desktop help that they can have on hand when editing levels. Version 1.0 only covers basic editing, with future versions to include heightmap, entity and other config settings that users find handy.
Anyone is welcome to download, and contribute or make suggestions to the project, which forms part of a series of tutorials on Sauerbraten I am planning.