NikiOo reacted to Radu for an article, 2017: Mapcore's Year in Review
(New logo by Yanzl)
I'm sure that by now most of us have our sleeves rolled up and are ready to tackle yet another year, but before we move forward let's take a moment to look back at what 2017 meant for our community. It was a time of immense growth for both professionals and amateurs alike. A time when everyone seemed to have surpassed their former selves. And without slowing down, some have even managed to land their first job in the industry. I don't know what this new year holds, what challenges to overcome will arise, but I know for certain that I'm excited to see everyone become even greater!
2017: Mapcore's Year in Review
Overwatch - Oasis
by Phillip K, Bram Eulaers, Helder Pinto and others
Dishonored 2: Death of the Outsider - Curator level
by electrosheep, kikette and others
Payday 2 - Brooklyn Bank level
by General Vivi
Sniper Elite 4 - Regilino Viaduct
by Beck Shaw and others
Counter-Strike: Global Offensive - Offtime
Team Fortress 2 - Shoreleave
Art pass, props and sound by Freyja
Wolfenstein II: The New Colossus - Farmhouse
Modeled, textured and composed by BJA
Half-Life 2: Downfall
Counter-Strike: Global Offensive - Studio
by ZelZStorm, TanookiSuit3 and Hollandje
Portal 2 - Refraction
Counter Strike: Global Offensive - Breach
by Yanzl and Puddy
Counter-Strike: Global Offensive - Berth
Counter-Strike: Global Offensive - Kaizen
by Andre Valera and Jakuza
Counter-Strike: Global Offensive - Asylum
Half-Life 2: Episode 2 - FusionVille: The Shadow over Ravensmouth
Unreal Engine 4 scene
by Dario Pinto
Counter-Strike: Global Offensive - Grind
by The Horse Strangler, `RZL and MaanMan
Counter-Strike: Global Offensive - Aurelia remake
Counter-Strike: Global Offensive - Tangerine
by Harry Poster
Counter-Strike: Global Offensive - Abbey
by Lizard and TheWhaleMan
Counter-Strike: Global Offensive - Apollo
by Vaya, CrTech, Vorontsov, JSadones
Counter-Strike: Global Offensive - Sirius
by El Exodus
Unreal Engine 4 scene
Counter-Strike: Global Offensive - Subzero
Counter-Strike: Global Offensive - Biome
NikiOo reacted to FMPONE for an article, Making a Map: CS_Museum
The creation of a map begins with an idea.
In the case of my most recent project, CS_MUSEUM, I needed a basic look which would resonate with players immediately. The thought of making a Museum worked… it was a simple one, it had been done before (although this wouldn't be a re-make of the classic DE_MUSEUM by Theropod-X). Players would understand a Museum environment, and it fit in the Counter-Strike world.
Forming a map’s final look is complicated, though, and requires thought about what kind of architecture, colors, and lighting you – an artist or level designer – will pursue.
I’d been playing a lot of the classic map CS_OFFICE, which requires players to storm into close quarters for indoor combat. That kind of game-play is fast and unforgiving, I dig the kind of matches it creates. CS_ASSAULT, I shouldn't forget to mention, is another great map that defines the "siege a building and rescue the hostages" genre. Actually, most of my favorite CS_ maps including Militia also foster similarly dynamic games that challenge you to be sneaky but also use brute force to accomplish your objectives.
So, I set out to make a hostage rescue map like Office and its kin. Studying prior maps is a good way to establish what works well, and avoid what doesn't.
One other map that influenced my thinking: CS_CABARET by Alex Roycewicz.
Cabaret is a great map — it got Alex a job at Infinity Ward long prior to that illustrious studio being kicked in the nuts super hard by mega-publisher-that-will-remain-unnamed.
It was from Cabaret that I basically ripped off the front of Museum... with a few changes.
In truth, though, I had some bones to pick with Cabaret.
Unforgivably, there was no sense of vertical space on the outside of the strip club. Also, while the building exterior is convincingly rendered, the overall space is too geometric: everything seems to face the viewer on an imaginary grid, which is no coincidence, that’s how the Hammer editor encourages people to make maps.
Cabaret on the grid:
Museum screws the grid:
If this analysis is starting to sound harsh, it’s worth noting that Cabaret was one of the best custom maps of its time, so this is more of a modern critique of older game art.
As is often the case with older game art, most of the limitations or flaws obvious to modern eyes were not the creator’s fault: Hammer around the era of Counter-Strike: Source (for which Cabaret was made) did not have all the technology I made use of for Museum. One example is “instances” (the pale green elements in the overview above) which are brushwork more akin to models than typical brushwork, because they can be rotated “off the grid” and not cause compilation problems normally associated with brushwork which is off the grid. Thanks to instances, I was able to rotate buildings to achieve a more natural, organic look — such as this bridge:
In order to actually create the specific buildings in the map, concept art and photographic references were key.
Here's an explanation of the Museum front.
The most pertinent point to make here is the difficulty of knowing when a photographic reference is valuable, and what makes it valuable. To explain this in extreme detail might be delving into an area of “talent”... or it might be worth the subsequent explanation I’ll now provide. In any case, this should explain my process.
The best photographic references share one crucial element: readability. Complex buildings such as the one above, if they are to be useful for our purposes, must be able to be broken down into clean, clear shapes. I was confident using the logic explored in the line-work above (I did this part in my head), that the building could be broken down and translated successfully.
The building begins to take shape, with the red lines becoming props. When using Hammer, what becomes a prop and what remains brushwork largely comes down to the default assets you have to work with.
Talented 3D modelers have their choice of creating new content, but their time is precious and each art asset is an investment, so even then it’s best to think about default materials and their role in your work.
This lovely picture inspired the placement of the obelisks, and secondarily the pond on the right of the Museum.
Using concept art and photos in conjunction with my imagination, I had derived a basic visual identity for the map:
Obvious reference: the Brooklyn bridge; non-obvious reference, this lovely piece from Deviant Art:
Making a map is about looking at the world around you and seeing something inspiring enough to create a desire within you to render it and mold it for your own purposes.
By this point in time you may be shouting IT’S A MAP – TALK ABOUT THE GAME-PLAY, TALK ABOUT THE GREY-BOXING YOU FOOL! …and, while the playability of Museum ended up better than I could have imagined, there is no glory in my process for that particular aspect of the map. Uh oh, he’s gonna say he didn’t grey-box it, isn’t he…
First, the excuses: previously, I'd recreated the Natural Selection 1 map NS_VEIL for NS2, based solely upon my own literal eyeballing of the geometry, without any scale-guide, in a different editor and a different unit system. To put all that gibberish into other words, I’d done nothing for two months other than study the rigid grey-boxery of another mapper, then spent another 10 months making that geometry fit into the context of a new game and engine. I’d worked with fastidiously organized layers, done everything by the book, guv, I swear.
While important for a commercial product, that experience had temporarily tired me somewhat of the (smarter) formalistic approach. As a result, no substantial grey-boxing would take place for Museum. Manic energy took the place of “rules” and “common sense”:
Basically, I was creating stuff I thought looked cool, not getting terribly fussed about what direction it would all head. This is the way newbie mappers work, or idiots, or both… but it can be done if you’re smart about it.
Certain things can’t be bullshitted around, though: your map must be in proper proportion to the players, and it must maintain sensible sight-lines considering the game type. You need to know the game you’re making the map for, and know it well.
So working free-form has its advantages, creating a whimsical sense of liberation in the budding mapper. It comes at big costs to him, though, in other aspects. This open doorway, and the entire route it signified, never made it into the final product. People have noticed its conspicuous absence, however, to the point that it may make it's return soon enough.
Working toward a result, with certain restraints in mind, but willing to cut: my method for Museum.
Mistakes were made. Certain areas violated basic good-practice principles, such as this one:
I call this piece of modern art “Abstract Red Light Number 48.” So… this elevator shaft was painful for a few reasons: too noisy inside, not clear enough about what it was meant to be, and the idea of it having a purpose seemed impossible given the amount of crap stuffed into the scene.
I believe I settled on a better, cleaner result:
Which was based off of this reference:
This shipping area was another idea that got cut (considering that it was over-dark, this was not too sad):
Everything else seemed to go swimmingly, however:
My biggest advantage when working with these references is my ability — and perhaps your ability as well — to discern from them what elements are most relevant and work best geometrically. These judgements influence what makes it into the map. While you may be able to follow a similar protocol by examining the pictures, you would be doing so in hindsight; it was quite necessary during this project for me to be able to sift through literally thousands of images in order to find those which, at first glance, provided the requisite inspiration.
References must be clean, they must convey a certain tone, and the architecture they illustrate must be plausible among the rest of the map geometry. This process of looking through seemingly endless references is a task which must be begun anew with every new map.
Back on topic: a month or two after starting out on the map, I recruited a talented 2D artist named penE who had a style congruent with mine. With his help, rooms like this began to form their own identity:
The map began to develop a sense of humor. We based the name of the museum on HURG — Hero of MapCore! (Don't ask.)
PenE brought his full enthusiasm to the project, getting almost all of his work done in a month or so, a rapid pace which would be a major motivator for me while I was working with (read: waging war against) the Hammer editor.
Here is a sample of penE's work for the map:
Nevertheless, the map did seem to require more art…
I had envisioned a T-Rex in the above room, and had designed the room around that eventuality. I was concerned that such a 3D model might not fit well (it’s a relatively cramped room), or might not be appropriate looking, but I put out a call for a talented 3D artist.
3Dnj answered that call with a stunning T-Rex model based on square-shaped geometric restraints. I basically stacked a bunch of cubes on top of one another and said, “OK now make me a T-Rex that fits inside the squares.” Seems hopeless, right? Thankfully, Valentin, as 3Dnj is known, e-mailed me this bad boy:
Owns right? Imagine waking up and seeing that first image of the T-Rex with that brilliant sheen, I was ecstatic.
At that point I realized I’d found a true collaborator and not just a “prop guy”. Valentin would go on to help me optimize the map, and reform a lot of my map geometry into more sensible models. Here’s how crazy things had gotten:
Hammer is unlike a modeling program in that it is “brush-based”, and things that are not literally six-sided cubes give the editor trouble. Trying to create an interesting shape out of a single brush? Take a hike.
So it’s obvious why a more extensive collaboration was needed: it was never going to be realistic to proceed in such a manner and expect an optimized result which would (ugh) compile. Hence, the logic of making a map which looks the way Cabaret does, unfortunately all the same limitations applied more or less in 2012, with just a few exceptions like instances.
So there were technical challenges, but four months on, most of the major lessons of the map were learned and my vision for the map was realized almost exactly as it existed in my brain.
My workflow can be best summarized as: find a fitting photographic reference, get a basic interpretation of the geometry into the game, and then polish with aesthetics and navigation in mind (lead players with lights and colors).
Rather than attempt to convince you I pursued the traditional level-design approach of iterating a grey-box, I hope this document serves to explain the approach I actually took: a risky and improvisational one that I know I’m lucky was successful. It’s good to state how lucky: a layout that emerged without argument, finding two brilliant collaborators with a lot of faith in the project, etc. Hopefully anyone looking to duplicate my exact method will be given pause, but at the end of the day there will always be logic in working hard and having a well-formed mental image of your goal.
As for Museum, I can promise you one thing: if you load up the map, and I hope you will, I think you will enjoy it. (If only for the giant, motherfucking Tyrannosaurus Rex.)
Thanks for reading.
NikiOo reacted to Froyok for an article, Technical breakdown: Assassin's Creed II
The following breakdown is based on my own guesses and how I understand the game from the textures and meshes I have watched. I can't tell you exactly if I'm right or wrong since I'm not a developer of the game. However, I believe I'm rational enough to think that most of what I say is close to what the developers have done. The purpose of this breakdown is educational and the work presented here belongs to its respective authors.
Anvil engine The Anvil Engine is a proprietary game engine used by Ubisoft's game projects for a few years now (the first game using it came out in 2007). We can call the Anvil Engine a next-gen engine since games for the previous console generation (like the Playstation 2) were using the Jade Engine at Ubisoft. The first project using this engine was the first Assassin's Creed game. Its initial engine name was Scimitar (before the release of the first game). Today, eight games are using this engine.
The engine has since been updated with Assassin's creed III under the name 'AnvilNext'. Mostly to support the new game challenges and configurations that we have today and probably to be ready with the future game consoles coming along.
Atlas and batching As with every open world and/or huge city, you have to deal with a very high number of resources. Mostly to keep the player in a fresh world and avoid repetitions. Games over the years have used various techniques to get past this problem. One of them is to reuse any resources that you have created. Creating a texture for only one object in this type of environment can be a problem in term of memory footprint. So reusing a texture will allow you to keep you memory low in size. Pretty obvious, however it's a hard balance that you have to deal with: diversity versus quantity.
The size of the memory is not the only problem that you will meet; the number of drawcalls is also very important. As a reminder, a drawcall is a call to the API (the functions of the GPU to draw a set of primitives). For each frame that you render, you have a certain number of drawcalls. Each time you call the API to draw something it takes a given time, regardless of what you want to draw. So you want to be sure to reduce these calls to avoid any loss of performance (taking too much time to draw a frame will reduce your number of frames per second).
Each time you change a mesh for a new one you will create a new drawcall, because for the engine it's not the same geometry. This rule applies for the shaders too. If you change the shader, you don't render the same thing, so you have to change the way you render it. This means a new API call.
A common solution to this is to batch your calls. 'Batching' means to group some meshes together before calling the API to draw them. This is why it takes less time to render a big mesh than multiple small meshes. How to batch these meshes if chosen by the engine, there is no best rule for this and it depends a lot of what you want to draw. In the case of the Anvil engine, you are focused on drawing large and open spaces. The best way to improve the performance in this case is probably to batch per shader. So each geometry using the same shader will be sent together to be rendered. This way, reusing textures will allow you to batch a lot of things and gain a lot of time.
So using atlas textures (multiple textures merged as one) will be a great benefit: you will reduce your memory footprint and you will use only one shader for multiple objects showing different things. Assassin's Creed II uses this system a lot for the environment and the characters. Since we evolve in cities, some houses are often similar, it is logical to find the same design multiple times. Which means that reusing a texture would not shock the player. It will even help for the visual consistency of the level. However, I believe that the engine was not perfect and due to some performance problems (maybe because of the dynamic lighting) they limited the number of textures. In Venice for example, you have an average of 1500/2000 textures in memory (including everything: sky, water, normal maps, shadows, characters and so on).
What do the textures look like exactly? In this game, textures for the walls are often around 512 x 512 pixels. Details, ornaments, water use 256 x 256 pixels most of the time. For example, the roof texture is only 256 x 256, but the tilling is so well made that it doesn't gene at all.
However, these textures being very tiny, the developers used vertex painting to blend details and break the repetition. Since there are almost no specular reflections in the game (probably to strengthen the feeling of the walls are made of bricks and dirt) the vertex painting masks are stored in the alpha channel of the diffuse texture. As you can see in the second screenshot below, the alpha mask uses very defined greyscales, probably because they separate each level of grey as a separate filter.
The textures are very bright, and we feel that in-game: the overall lighting is itself very luminous.
Levels of details Dealing with an open world means dealing with a very long view distance. Therefore, the farther you see, the more you need to draw. Unfortunately you are limited by the hardware (especially on consoles) and you will have to use some LODs (level of detail). The developers have chosen to let the LODs 'pop'; this means no blending transitions between them, which is visually ugly since you notice the change.
The environment collisions are dissociated from the visuals mesh. Probably because you can more quickly hide/disable the collisions of the environment since they are not visually displayed on the screen. This explains why forcing the LODs of the environment allows you to... climb the void!
On the PC version, you can increase the minimum distance for when the environment starts to blend (which is something like 40/50 meters if you blend at the furthest possible distance). It's also interesting to note that some props like barrels, crates and other little things are independent of the global LOD distance. It seems that some props are linked to the LOD of the building mostly because they are at the roof level, while props in the street have their own blend distance.
Characters Pedestrians in Assassin's Creed are based on modular characters. The developers use a set of heads which are combined with hands and different clothes. While the hand and heads have their own details and colours, the clothes are just a totally grey shared texture (except for the letter) and coloured in the shader to add variety in the game. They also add a detail texture to break the linearity of the clothes and bring up some fine details. Characters have also their own LODs.
During a presentation at GDC 2008 about the first Assassin's Creed, Francois Levesque (a technical director on the game) explained their pipeline to produce a lot of different characters without losing too much time. They used a base head which blends to fit to the high-res character. This way they automatically get the LOD mesh at the same time since the meshes always shared the same topology. The only update to do was for the position of the bones on the top of the vertex to keep their skin deformation.
Since meshes and UVs are similar, it's easier to manage and create a crowd dynamically. So there are maybe 5–10 different clothes and then the game dynamically creates a character to add it in the game scene. In the first Assassin's Creed, characters had 2 LODs, which meant 3 meshes per character. In Assassin's Creed II it's the same thing. However it seems that the clothes and the head don't blend at the same time. Probably because they don't have the same space occupied on the screen. So the heads go to their first LOD mesh sooner.
You can see some examples on zBrushCentral with the base mesh topology and also the topology of some bodies used by the game.
Lighting The Anvil engine is an engine developed to mostly show open environments. With the development on this second opus, they wanted to add a day-and-night cycle. To achieve this they naturally chose the cascaded shadow maps technique (more exactly, Parallel-Split Shadow Maps as described in a GameDev.net forum thread) which even today is the best way to draw a unified shadow on such big environments.
There is no Global illumination at all, it's mostly only a main directional light (the Sun) combined with an ambient colour which evolves during the day. Some interiors like the tombs present localised point lights; there are also some point lights which are enabled during the night.
However, regarding the performance, they were obliged to use a very low resolution and a blend distance. This explains why you see a lot of blurred pixels on the ground/walls for the shadow. This is also why you so clearly see the blending of the shadow from one level to another.
Some shaders use the Fresnel term to enhance the looking of the character clothes a bit, but most of the time they simply use direct lighting without complex shaders (again, because it was very expensive). There is no fake sub-surface scattering (SSS) for the characters, even during the cinematics. The SSS only comes in with Assassin's Creed: Revelations and will be improved for Assassin's Creed III.
Conclusion Assassin's Creed II was a really good improvement compared to the first game, however it looks like the engine faced a lot of new constraints which were not totally well handled. The way the LODs appear and the nice but still limited quality of the lighting are good examples of that. Even on modern computers today the game gets some slow-down in certain places.
The engine was improved for the next game iterations and increased the amount of details and the quality of its lighting to finally show beautiful cities as we can see in Assassin's Creed III today.