Lighting is one the most important parts in mapping for Cube 2. This article is directed to new mappers, who are not yet familiar with the very basic aspects of lighting. Most of it should apply for other Cube-Engine-based games (the default keys may differ, though).
First I will introduce some basic commands, then I will explain the most important general light settings of a map. The following part deals with the usages of light entities. The last part contains some thoughts about the lighting-tab of the ingame menu.
The are way more commands and features which are involved within the lighting of a map, but I'll come to that later.
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 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 there doesn't seems to be any guide or what so ever of how or why to star a certain content, maybe it's about time to do so.
I'll focus on maps just because those are the most starred content on Quadropolis.
You can have certain reasons to star a certain content, but you should always keep this in mind first (in the very same order):
- Is the map really that good on every single point (as in theme, texturing, detailing, lighting, (and clipping, flow and gameplay as well if it's a gameplay-based map)?
- Is it truly better as the average content on Quadropolis?
- Is it containing a certain originality which it separates itself from other maps again (while still being balanced in other points!)?
- Is it really what we would like to see as example for other mappers?
From: http://qreeves.blogspot.com.au/2012/06/understanding-open-source.html
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:
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!!
Entrants should follow the following guidelines for entries into the competition:
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.
I: Thou shall not infringe on copyrights.
II: Thou shall not make gimmick maps.
III: Thou shall not post a map that took less than 12 hours to complete on Quadropolis.
IV: Thou shall not use the clip/noclip materials in thine first three maps.
V: Thou shalt not capitalize file names.
VI: Honor thy Aardappel and Eihrul
VII: Thou shall not create spawn points facing a wall. This includes both monsters and playerstarts.
VIII: Thou shall not use the smallest grid size to create an entire map.
IX: Thou shalt not touch the lighterror variable. Ever. I will break the face of anyone who does.
X: Thou shalt not be a douche bag on public servers.