Asset planning
---------------------------------------
Are you familiar with that phenomenon, lot's of ideas and discussion, but little productivity? Whether you make a game, or have a meeting at work about implementing X, people are enthusiast in making ideas and good in chatting generally. But as soon as you really need to pick up the worktools...
Not familiar with that? Good, that means you are a "worker" :) So we had ideas, floorplans and a few shitty sketches ready for this Radar Station. Now we just had to... build the whole damn thing. Talent and enthusiasm all over the place or not, the team needs to be instructed. If you expect all your "employees" to take initiative and fill your mailbox with finished goodies every day, you'll be disappointed. If you are in charge of a project, it's your duty to push, stimulate, feedback, and make clear goals. Artists are often ready and happy to do something, but they need your confirmation. Like a sniper needs a “fire” signal. Like the red telephone needs to ring before launching the missile.
Ok, so what I did were 2 things:
- Make a simple asset listing in a Notepad file
- Made an Asset Database where details, progression and author info could be stored per task in a database.
Making a global list is simple, but important. I knew which rooms we had to make, and had a rough idea of the room-contents. So for each room I made a list of sub-assets. Floor textures, wall concrete, dirt decals, a rusty bed model, a metal rack with stinky boxes, and so on. Asides visual assets, there were also audio assets. For example the sound of a computer or airvent. And of course programming tasks. If we want snow falling in, it also requires particle generators and shaders in the engine. For each week, I assigned a couple of assets to the team members. PersonA does a concrete and pavement texture, personB makes a barrel object, personC records goat sounds, and so on. And so I planned the next 10 weeks forwards.
Asset, but in a database. Properly managing a database takes extra effort and discipline though, so a simple textfile might be best to start with after all.
The magical factor of a successful planning is the feasibility. If you load too much on personA, you can redo his planning 2 weeks later on, because he already got behind. If you plan tasks for personB he doesn't like, the same will likely happen. If you leave no room for people being busy (work, sick, family, abducted...), same story. And don't forget more assets will automatically pop-up on the go. Unless you can look in the future, it's near to impossible to foresee each possible (sub)task. Be aware the amount of tasks will grow. If the planning is way off realism, people will discard it, and it has become a worthless piece of paper…
The easiest way to prevent this, is planning very little. But hey, that's not very stimulating either, and it will delay the release of course. It's ok to push people, as long as there is time to breath. Plan the unforeseen. What I did is making a "deadline" end November, though I already knew we most probably would need entire December as well. I also planned 1 empty week halfway, just to catch up things. On top, I "sinused" the weeks. 1 busy week with 3 assets for example, 1 easy week with only 1 asset, then a busy a week again, et cetera. if personA would be busy fighting with his girlfriend in week3 for example, he could move his tasks to the next "easy week". And of course, I asked everyone if the planning was doable.
The nice thing about plannings and deadlines... Once people agree with them, they have a commitment. If the team nicely accomplish their tasks according to the planning, the individual feels forced too. No one likes to let down the team of course. That may sound a bit like being forced to do boring homework for school, but don't forget that we assigned voluntarily to make a game. Shaking Turbo Pascal code or making 3D vases is our hobby... uhm, if the pace goes well, and progress can be shown each week, it's fun to put effort on it. The demo movie and hopefully positive reactions are the reward. And an actual game-release, making filthy money, get famous, wear lady Gaga masks, sniff Heroin and be on the set with 5 naked girls in a new Snoop Dogg track (or just getting a contract at Nintendo) is the pot of gold at the end of the rainbow.
Mapping
---------------------------------------
All right, time to actually do something. So I called Morgan Freeman for voice acting, Sean Connery for texture drawing, Neil Armstrong for the sound and Madonna for the 3D props. They were busy though, so I had to rely on my few team members. Julio on the drums (textures & drawing), Sergi on the Guitar (3D objects to fill the rooms with), Brian on the flute (Website), David on the synthesizer (audio). Later on Robert on the contrabass (monster), and me on the Xylophone (programming & maps).
There are million ways to accomplish something like a Radar Station. Do the textures/props/audio all separate, parallel. Hire a couple Polish construction workers, or use the empty rooms as a framework. I chose the latter. Once you have rooms, you got something to show. From that point, it's easier for others to imagine how a room could look with textures, objects, or how it should sound (see pic above). As a bonus, their assets can be directly tested within that room, inside the game or editor. Don't underestimate the effect of direct feedback! If one makes a chair that will be used a few months later, it's difficult to tell if the chair really fits there. And getting back on your old models months later sucks. Just bring it on and get over with it at once.
Baking the mesh
So, I made all the empty rooms first. Normally mapping is not my task, but since this bunker has relative simple shapes, and the lack of manpower, I took the job. Plus I got pretty fast with Lightwave, doing tricks with cubes for years and years;) Nevertheless, if you have experience with 3D modelers you'd better close your eyes the next few paragraphs, or you may get a heart attack.
It's pretty simple really. First I plot the floor points, then connect them as 1 complex polygon. Then grab that polygon and extrude it into the height. Flip the faces inwards, voila, a basic room. Repeat this for all rooms in the scene so have a bunch of cube-like rooms. Done… Wait, they need doors and windows. In Lightwave, you can toggle to a second layer and create cubes(or another shape) between the rooms. With Boolean operations like "Subtract", "Add" or "Union" you can use these second shapes to drill holes in walls on the first layer, or to connect the meshes.
It already starts looking like a structure now. But to make the rooms more interesting, it needs some Gaudi twinkles. Pillars, skirting, windowsills, play with heights and stairs, pipes, et cetera. The knife-cutting, extrude, and boolean tools are your friends in Lightwave.
Got to mention that the rooms are not equipped with fine details initially. Stuff like wall-sockets, electro cables, doorknobs, broken bricks, furniture, metal railings, doors or lamps are added later as separate 3D objects, or as a special detail layer in the map. The map itself has a relative low polycount to optimize things like collision detection or background rendering passes that don't need the little details. Then again, surfaces do get subdivided into smaller square tiles, and that quickly adds a lot of triangles again. Why is that? Because we store data per vertex for "terrain drawing" and static occlusion values for simple ambient lighting. The more vertices you have, the more detailed you can bring in that. Plus as a general rule, you shouldn't make huge or very thin & long polygons anyway, as they can cause slight interpolation errors. If the normal on vertex X is a bit bended, the connected polygon will show that off in its lighting. If that polygons is huge, you can clearly see the triangular structure of the map, which is not good usually.
A folded, but flat quad... looking like shit due bad triangulation.
UV
Last but not least are the UV coordinates. No, that's not a term for sunburn degrees. These are (secundary) coordinates that tell how a picture is wrapped on your walls, floors, or whatever surface. With these coordinates you can rotate, shift, stretch or deform the way how a picture appears on your walls. Doing UV's is simple with Lightwave... But doing them exactly right takes time, and is as exciting as watching Karate Kid 8 times in a row. Very common errors each gamer probably has seen in the past 14 3D years:
- Scaled too small. Do I need glasses, or do I see the same crack 10 times over and over again? See floor in pic below.
- Scaled too big. The wall from nearby looks like a blurry N64 texture. See right cube in pic.
- Wall shifts. The painted stripe is 3 cm higher or lower on the neighbor wall. See red arrow.
- Stone tiles do not exactly fit in the room, a small strip still appears next to a wall because the scale and/or position was a tiny bitt off.
- Truck-ran-over-cat-stretched-stripes.
Shit happens. Sometimes the artist forgets to define the UV coordinates for a corner.
See center cube.
Honey, who stretched the kids?
But because I found UV-mapping just too boring, the Tower22 map editor has some paint tools that helps automatically scaling and shifting which saves a lot of time. So, no, I didn’t do any UV-mapping at all in Lightwave. Except for the complex shapes such as pipes with curves. That's because the Tower22 UV tools are too stupid to handle those (for now). And that's also the reason you may see some badly mapped polygons in the movie here and there...
Enough for now. Next time the last step of map-building, importing the maps it into the game!
Close, but no cigar
No comments:
Post a Comment