This page is part of the old artists' documentation which has been replaced. It is kept here for reference, since there is the possibility that some content is missing from the Art Portal. However, be aware that this page is no longer maintained. It will contain obsolete, inaccurate, or incomplete documentation and is not recommended as an artist's resource. Please see the community page for links to current documentation.
- This is the official guidelines for Supertuxkart 0.9 and upper. Currently the reference track is Cocoa Temple.
- These guidelines are hard rules you must follow them otherwise we won't include your track in the main package (of course if you want to make addons you can use your own the style.
- If you want your contribution to be part of a certain package (like the main-package or a special add-on/mod), discuss your idea with the community before putting too much effort in it, and send us your track on a regular basis, so styling issues and gameplay can be discussed before being spread over the whole model.
- If anyway possible, use blender for your creations and send us the .blend-files together with the exported models. Blender offers you the best tools and esp. for tracks, there is just no way to get around blender, yet. Most of our current artists use Blender and can therefor be a better help, if they get the data as a .blend file. Further note, that .blend files can really help us to improve and care for your models in the future.
- If often best to make it clear if your track is complete or if you still plan to improve it. We will show interest if we think about adding your contribution to our official packages. We will try to give feedback in that case and afterwards wait 'till you tell us your project is finished before we do another review.
- Official unit system is metric . So all signs, units etc are in metric.
General (for karts, tracks, etc.)
- The Supertuxkart universe is colorful and contrasted but not too much. It's not a too cartoon game. It uses hand painted realistic textures and realistic object. The finished result looks like a concept art or similar to Team Fortress 2.
- This does not mean you cannot do darker stuff, but they should remain caricatural in a way that makes them not too grim.
- Do not overdo the light mood though ;) Avoid putting too much different colours together on the same screen in a way that hurts the eye. You must define a color palette before starting to make your track. A color palette is what is the main color that you will use to make this track. Of course a red barrel will be alway red. But the general atmosphere needs to have one or two color. Each tracks should have it's own palette. Thinks about how you can tell a story with colors to help you to choose the right palette.
- Avoid 100% black or 100% white. You loose the color information when an area is 100% black
- The textures should be hand painted and realistic but DON'T USE PHOTOS, Of course you must use real photos as documentation. For a generic texture the and colorfulness and lightness should be neutral since lights and shadows are provided by the game engine and colors are provided by detail texture. If a texture is too dark even a very powerful light cannot lit its and if it's a texture is too bright it will bloom even without a strong light.
- Standard size for generic texture is 1k (or 1024 * 1024 px).
- Remember the blend mode between a generic texture and a detail texture is multiplication. It means that things can only go darker (at this stage). Avoiding too dark generic texture allow more flexibility with detail map and avoiding too dark detail texture allow more flexibility with lights
- Don't use candy-colored, plastic-colored or plain-color textures. These should be banned.
- Don't use textures where you can easily see the tiling/repetitions. Easy-to-spot repeating patterns are banned.
A bit of history
In the old days of gaming it was impossible to compute perfect lights for all pixel. All intense computation were done for each poly and then extrapolated to the pixel inside the poly.
But nowadays modern engines like stk uses per pixel light. So the most complex part isn't the vertex shader but the pixel shader. Let's take this example with an object that has ~500 polygons Basically for the GPU managing a vertex is maybe ~10 instructions (it's not the exact number, just to give you an indication). For each poly of your model the computer will do ~10 instructions, 500 * 10 = 5000 instructions
Now, the pixel part. It will depend on how many pixels will be took by your object, but let's go for a worst case scenario let's assume the whole screen is filed with your object For each pixel to compute (the light, the gloss, the normal map, etc) it will take let's say 50 instructions to the gpu if you have a resolution of 800*600 (most people have higher resolution).
800 * 600 * 50 = 24000000 instructions So even if you double the amount of polygon you won't affect too much where the vast majority of the power is spent. It's on pixel not on poly anymore.
Thus we can increase the polycount without too much troubles. However it's important to keep its under control.
- The polycount for a track is ~290,000 poly
- The polycount is a target, not a limit. But it's not a reason to waste poly in place where they don't need to be.
- Try to keep an appropriate balance between high-poly and low-poly. For instance there could be a style problem if you put a high-poly sphere next to a plain cube.
- Objects that are always seen from far should not waste poly.
it's smoke and mirror ^^. As soon as you go off limit, the geometry and details are cut down for performances. Many part aren't done or just very basically to suggested a vast unlimited landscape.
Here is an example. In the left view (near the player) you can see everything as a lot of detail, you have vegetation, palm trees etc. Pillar are highly detailed, the fence too. In the right view a lot of details has been cut down. The ocean has no floor (in fact it's the skybox), pillars are very basic and the fence has no grid and barely some wires.
However when you see the whole landscape from the player's point of view, you can't see there's a lot of stuff missing in the distance.
- STK needs to run on a wide range of computers, and thus we need to avoid very high-poly stuff. Try avoiding using huge amounts of mesh - especially where you can't see the difference, or in places the user is not likely to (or can't) see.
- DON'T put objects in places that cannot be seen during a race.
- Here is some polycount of objects in the new version to give you an idea
- A cargo plane: 1500 poly
- A palm tree with LOD
- High: 800 tris
- Medium: 400 tris
- low: 82 tris
- A basic plant: 600 tris
- A medium sized tree: 1200 tris
- A pumpkin: 255 tris
Track guidelines for the official packages
- For the visual style, take inspiration from Cocoa Temple and for lighting from Old Mine
- Before opening blender, you must look for documentation. You need tons (100 is a minimum) of photo references, maps, etc. about the theme of your track. You can watch videos on the internet to see how it looks in reality. be CURIOUS!
- First and foremost : think about the shape of the track. Even if you are an experienced modeller and make a track that is very nice-looking, the nice visuals will be of no use if the track is boring to drive.
- Avoid making the track too narrow since this makes it hard to overtake other karts.
- You have to make concept art. Determine where buildings, objects, structures etc. will be located. You can also make a very basic track with only the path and blocks to show where buildings might be. You can see if the gameplay is interesting.
- If you want to add something special (like water flowing) you need to look for documentation about this effect. How is it made by professional games? You can try to make it in a mockup before you integrate it into a track.
- Avoid making the track too long. Over 1:30 is definitely too long; between approximately 1 minute and 1 minute 30 seconds is considered appropriate for one lap without using boosters and other items (like nitro).
- Always try to find an appropriate balance between straights and turns. Too many straights may be boring, but too many curves (especially very tight ones) will make the track hard to drive.
- Playing at SuperTuxKart should be an epic journey in its fictional universe. Avoid using too much city/industry elements; instead explore lots of different, exotic and even unexpected locations in the STK universe. Prefer known and coherent universes/worlds (fictional or not) over a bunch of colorful non-sense (i.e. use consistent themes referring to real-world places, stories, past civilizations, etc.) Use your imagination to come up with something original yet coherent.
- Avoid names like Tux's Inn or Gnu's Bar. It's a lack of imagination. We have some fictional company names that should be used
- Avoid very (and even moderately) steep slopes, as the physics engine will have trouble with them.
- Avoid dead ends/corners in a track. I.e. places where a kart could fall down or get stuck. Examples are falling down into a corner from which no way out exists, or getting stuck on a fence with the chassis.
- Avoid facades that look awful as soon as a kart leaves the road. Your track should have a beautiful landscape. The new version of STK has a render view of 16km if needed.
- Re-use textures and objects from the object library instead of creating new ones when possible. This helps keep the size of the game down and it's easier to update and maintain the game.
- Keep the style consistent throughout the whole track.
- Make sure you add a starting line texture (checkered line) so that people know where the finish line is. Preferably use the check.png file as a texture, but if it doesn't go well with the style of the track, feel free to use a different style.
- Use the sky shader as much as possible. STK > 0.8.1 supports complex animated sky, so don't fake a sky by using a mesh. If you want to put an object "in the skybox" you can use a dedicated feature called 3D skybox.
- Integrate your track in the environment. No flying tracks unless they make a lot of sense. You better discuss your arguments before starting to work on such a track if you want it integrated in any of our packages.
- About checkpoints: they should only be used to stop major shortcuts (e.g. driving in small circles around the starting line and crossing it over and over again). They should only be places at places where the karts have to drive through, and they are not meant to stop minor short cuts (e.g. to avoid a kart driving straight through an "S" shaped curve). Use the terrain and physics (slowdown when being off track) for that. Make sure the checkpoints are wide enough that a kart driving off the road will still trigger it. Checkpoints don't have to have a visual representation in the track (see track exporter for more details).
Kart Guidelines for the official packages
- For the visual style, take inspiration from karts like Suzanne, Emule, Pidgin, Nolok which show approximately the style we are looking for.
- For the main-package: karts should relate to a certain open-source mascot.
- Ideas :
Gnu, Pidgin Bird, SUSE Chameleon, BSD "Beastie", Mozilla Firefox, Mozilla Thunderbird, Blender Monkey, KDE Dragon, Ogre, Windowmaker Panda, Perl Camel, PHP Elephant, Snort Pig, Workrave Sheep, XFCE mouse, Python, Adium Duck, Tortoise CVS/SVN, Cairo Insect, Mantis Insect, etc...
- Ideas :
- Their style should be cartoonish and not to serious or futuristic.
- Avoid plain colors and plastic-looking karts
- Don't add outlines (those should be a feature in the engine if we ever feel like we want them)
- Keep roughly the same size as the Tux Kart (to be friendly with the physics engine.) Especially avoid making the kart thin and tall.
Final notes on inclusion into main or add-ons
- The visual quality of SuperTuxKart has steadily improved from version to version. We thus have to say that unfortunately we can't accept everyone's contributions (but you may put them on the add-on site). Keeping the visual side improving is important to achieve a high-quality game. Therefore, in general only contributions from people with decent blender experience will go in. If you are new to blender, you are free (and even welcome) to try learning by making tracks; however it must be said right from the beginning that unless you learn very fast or have natural talent, your [first?] tracks will most likely not go in main. Note, however, that there is nothing preventing you from releasing your own add-ons on the forums, to share with others.
- Finally, a final note that, while not really related to art of style, does apply : some humility does help ;) e.g. please don't repeatedly post comments like "when will my track be added into the main package?" or so. This helps keep a better mood in the community in general ;) If your track is high-quality, we will surely see it and show interest. If otherwise, don't worry. Make new tracks, get more experience, and improve the track. And after all there always is the add-on site.
- Of course, while this is not a style issue, absolutely make sure to consider Licensing if you wish your work to be integrated into the main package (or add-ons).
- It's hard to give precise guidelines for songs but here are a few items to watch :
- Music in STK should not be too heavy or too electronic.
- The style of STK requires songs with melodies more than ambient soundtracks.
- Do not make songs too long since we try to keep the file size down. 2 minutes might be an example of a good length.
- Do not make the song too repetitive : a song that always has the same beat repeat over and over with only minor variations may be rejected.