Shifting the burden of creating tile-based artwork to the renderer

I recently finished making a game for a contest. A lot of the other entrants used tools like Construct or Game Maker, but I decided to go with what I’m most familiar with — C++. I made use of Box2D for simple platformer physics, and I ventured into some new territory with OpenGL and OpenAL with mostly positive results. Long story short, spending two months developing with nothing but Visual Studio and tools of my own creation made me realize anew that I really enjoy coding. I’ll no doubt spend most of my time on school projects from now on, most of which will be level design or UnrealScript, but I’ve decided that I’d continue to make an active hobby out of creating small games from scratch. Since I’m necessarily moving at a more leisurely pace, I now have the opportunity to plan and document more carefully, so I figured I’d use this old, neglected blog to do that. Mind you, these aren’t tutorials and I’m by no means an authority — I’m more or less thinking out loud, except with laboriously constructed diagrams.

This last game was a platformer with tile-based graphics. The problem with tile-based graphics, if you’re doing them the old-fashioned way, is that you end up making a lot of redundant variations of the same tile if you want them to end up looking presentable. There are cases where it’s good to have direct, pixel-level control over how things look, but much of the tile work I was doing in Photoshop could have been handled procedurally, on the fly, in the game itself. Since I’m aiming to streamline the level creation process as much as possible, delegating to the computer the task of combining different sets of graphics in a way that looks pretty is one of my first goals.

Here is a sampling of the many individual tiles that were required to make a set that still had a lot of pieces missing. Your average tile consists of a base texture, which is the same across all tiles in the set, and an overlaid trim that’s edited to fit the shape or outline of a particular tile. All of the tan brick tiles could be boiled down to two textures if the base layer and the trim layer were rendered separately by the game, and the trim layer properly wrapped around the edges of the shapes in the level.

I’d like the game to be able to generate something like the above on its own, given those two textures and the user-defined shapes, in the form of a list of vertices.

Although you can easily get away with only having a certain set of predetermined ’slope’ tiles, I figure now is as good a time as any to start venturing beyond the SNES-era notion of tile-based levels on a clearly-defined grid. I decided to work on a way of rendering overlaid trims onto arbitrarily defined shapes. Here is that process:

A 2D shape comprising edges of arbitrary angles is drawn. This example uses a convex shape with vertices drawn only on gridlines, so that if the shape were to be divided into grid-spaced tiles, each tile would have no more than 4 vertices defining its shape. Whether a tile-based approach will be used, or whether more finely detailed shapes may be drawn, is yet to be determined.

A base texture is applied to the shape, in this case sourced from a single, tiled, 32×32 image. To go with the grid-spaced tile paradigm, each vertex is drawn translated outward from the center position of the tile. The UV coordinates for each vertex are determined simply by translating the relative vertex position into UV space.

A trim texture is selected, sourced from a 32×32 image in the same format as the base texture. Thanks to transparency, trims may be of any thickness up to 1.0x the height of the image, and the trim placement algorithm does not require (or allow, if you prefer) the user to explicitly specify a desired thickness. A starting location is chosen, and the process about to be described is repeated edge-by-edge until the shape is closed. In this example, we start at the uppermost and leftmost vertex, and work clockwise.

Note: These steps work through what should happen conceptually, or how a human would lay things out. An efficient, programmatic approach will be divined once the process is completely described in these terms.

First, the distance of the edge is measured. Distance((-0.5, 0.5), (0.5, 0.32)) is 1.016, which tells us how long our trim quad needs to be.

The top-left corner of the appropriately-sized trim quad is placed at the vertex in question, becoming the anchor point for rotation. The rotation of the trim is determined by finding the angle between the horizontal and the vector formed by the edge along which the trim is placed.

The preceding steps are repeated for the next edge:
From (-0.5, 0.32) to (0.26, -0.5), distance 1.118
Vector2D(0.76, -0.82), slope angle 47.17 degrees

The edges are joined properly, but with some overlap. In order to produce a seamless transition, the overlapping area needs to be clipped off.

The edge along which the clipping should occur extends from the vertex which adjoins the two edges, along the vector halfway between the two edges (the inverse 2D cross product of -A and B? You tell me). In this non-programmatic approach, we delete everything to the left of the clipping vector.

In the actual impelementation, this information will be used to modify the bottom-left vertex of the trim quad before it is drawn. Recall that a trim texture, transparency and all, is square. The orange rectangles below outline the actual quads to which the trim textures are applied. In local coordinates, their width is equal to the length of the edge, and their height is always 1.0.

Vector C is the line which runs from the edges’ adjoining vertex through the intersection of the two quads’ bottom edges. This intersection point becomes the new bottom-left vertex of the trim quad. The UV coordinate at this vertex is (u, 0.0), where u is the distance from the original (non-clipped) bottom-left vertex to the new bottom-left vertex.

The process is repeated yet again:
From (0.26, 0.5) to (0.5, -0.5), distance 1.028
Vector2D(0.24, -1.0), slope angle 76.50 degrees

This step identifies a flaw in the process: If the edge to which we’re adding trim forms an acute angle, the edge of the trim will extend beyond the bounds of the shape. One possible solution is to mask the trim to the underlying shape, but it’s probably computationally cheaper to alter the bottom-right vertex of the trim quad in the same way that we already alter the bottom-left.

As I mentioned earlier, the so-called clipping vector for the bottom-left vertex is based on the current edge and the previous edge. Similarly, the clipping vector for the bottom-right vertex will need knowledge of the next edge as well as the one currently being iterated over in the trim placement process.

This case is simpler, however. The clipping vector for the right side is simply the next edge in the chain. The new bottom-right vertex is the point at which the next edge intersects the bottom edge of the current quad, and its UV coordinate is (u, 0.0), where u is equal to the length of the edge minus the distance between the old bottom-right vertex and the new one.

Note: You will see momentarily that this is not the best way to solve this problem. However, this is not a tutorial, but a documentation of the design process (which often takes place very late at night, I might add). I prefer to leave such momentary lapses in judgement intact in order to demonstrate how poor design choices can be avoided by taking the time to plan things out before implementing them. You will make mistakes, so it’s best to make them all as early as possible, when they can still be easily corrected.

cur: (0.5, -0.5) to (-0.5, -0.5), d 1 | (-1.0, 0.0), angle 180
next: (0.5, -0.5) to (-0.5, -0.15), d 1.06 | (-1.0, 0.35), angle 160.71

In the case of an obtuse angle, the next edge never intersects the current quad, so the bottom-right vertex should only be clipped if the angle between the two edges is greater than 90 degrees.

Additionally, because the corner formed by this edge is acute, it is a triangle rather than a quad. This is a separate issue that will be addressed in the implementation.

The process is repeated for each edge until we return to where we started.

This last overlap is a bit of a special case. Since each edge covers up the previous edge, we normally don’t have to clip the right edge except in cases of acute angles. However, assuming we draw the edges in sequence, one on top of the other, there will be an unavoidable overlap wherever we start and end.

The quick solution is to add a special case that would clip the right edge of the last trim quad. However, adding such functionality to the normal trim placement process would solve this problem as well as the previous acute angle problem without the need for special case logic. Additionally, it would be essentially identical to the process used to clip the left edges. The performance difference is negligible, but it will result in much more elegant code.

—

A shape is a series of edges. In our shape creation process, of which trim placement is a part, the edges need to be in a doubly-linked list, so that any given edge is aware of the edges before and after it. Using this information, the trim placement algorithm will determine the proper vertex positions and UV coordinates for each quad/tri, and then apply the trim texture, requiring no additional data describing the thickness of the trim.

No implementation has yet been written, and some details are still up in the air. However, we’ve come up with a decent procedure for adding trim to a shape. By articulating every step of the process as well as running through it by hand in Photoshop, I’ve been forced to critically evaluate every decision and to make sure that the code that will result from this plan will be thoroughly designed, free of hastily-made errors, and if nothing else, well-documented.

Chernobog, Week 9

I’ve made a lot of progress on this game since the last post, but most of my efforts at documentation have been directed toward unnecessarily detailed SVN comments and the project’s technical design document, which is in desperate need of an update.

The last few features were implemented kind of hastily for the final submission of the class, but everything else is fairly flexible and as elegant as I know to make it.  Most everything external is loaded from XML and stored/accessed on demand via a ContentManager class, making updating graphics, sounds, tilesets, levels, etc. a breeze.  The basics of a platform game are in place, with Box2D-simulated physics, generation of physics bodies from the tile-based map, collision triggers, a traversable map with multiple rooms, some UI components, and a basic platforming mechanic that involves spawning red balls from thin air and using them to push the player and other sprites around.

Aside from cleaning up a few of the latest classes, I look forward to adding some kind of AI abstraction once I have the time, as well as whipping up a level editor, and I’ll be on track to making this more of a game.  The current exe is up here (WASD, Spacebar, LMB, RMB, 7).

The Heaviest Corner on Earth

A few screenshots from an environment art project I worked on a while ago:

Chernobog, Week 2

I made pretty good progress on my SDL project this second week. It’s approaching the point where I could start writing some game-centric stuff and have it reasonably integrated into a handsomely designed framework. There are definitely a lot of chunks missing, and a lot of what I have will inevitably need expansion, but it feels like it’s shaping up. Since last week, I’ve added timing functionality (for regulating framerate and animation speed), event handling for user input, and movable sprites which can display frame-by-frame animation.

Here’s a ghetto diagram of the important classes. (One of these days I need to learn how to make honest-to-god UML diagrams.)

And here’s a video showing off keyboard/mouse input to move sprites, as well as sprite animation and the recently-hacked-together text display class. Jefferson animates when he moves — the screen recording skips too many frames for it to translate well to video.

I’m finding this all very fun, and I’m getting to the point where I’m comfortable enough with these things to fluidly express my ideas in code without excessive limitations. I owe a lot of that comfort to watching the lectures from Harvard’s Intro to Computer Science course over winter break. I doubt that ITGM415 will require me to deal directly with cryptography, or data forensics, or sorting algorithms, but being exposed to the implementations of these things has helped a lot. Especially with regard to memory, knowing how things work at a lower level than is traditionally taught in programming classes at art school leaves me with far fewer questions on how to efficiently solve problems.

There’s much more to do. For the immediate future, my sights are set on text display and some more advanced drawing functions. I also need to work on sealing and preventing memory leaks, and a big part of that will be writing an XNA-style ContentManager class that keeps track of external files to prevent redundancy, streamline cleanup, and confine the loading of files to predetermined times. Next week is also my target date for having a tile-based Level system in place, including reading from file, drawing, scrolling, etc.

Chernobog, Week 1

I’m taking a class called C++ Programming II this quarter, and at the end of the quarter I will have an unfinished game that will be as close to presentable as I can make it in ten weeks.  I’m documenting it here to track my progress and see how far I can take it week-to-week.

“Unnamed Project for C++ II” doesn’t exactly roll off the tongue, so I gave it a working title.  It comes from a 12th-century Slavic god named Чернобог.  Whether the game will actually involve Slavic mythology is not clear.  I’m aiming to make a platformer in the vein of Super Metroid, for the specific reason that it’s more challenging to engineer than a strategy game or some out-of-the-box artsy thing.  The art will be placeholder city, the software architecture will be amateurish, and the whole thing will be woefully incomplete, but I’m putting as much time into it as I’m able.

One restriction is that I use SDL, which is written in C, so the first order of business is wrapping it into an object-oriented framework that will be easier to use as a client.  I got some first-hand knowledge of C from CS50, but I can’t fathom how people managed to organize complicated things like games and multimedia libraries before C++.

I learned some rudimentary XNA over the break, and that’s paying off now because I’m ripping off its basic architecture like nobody’s business.  So far, I have the Game object in place, with various graphics classes simplifying the process of loading and displaying images, as well as a couple of helpful utility classes.  I’ve got plenty of steam left; this is just an arbitrary end-of-week update.

Here’s a fake diagram of the class organization:

And what it does, which is pretty boring as yet:

To do in the immediate future: Sprite class, Keyboard input, Animation class, SpriteManager

Things that are important in Source mapping

These are but a few things I’ve learned through the mistakes I’ve made in a few weeks of mapping in Hammer with custom props.

1. Grid size of interior spaces

I don’t just mean building on a grid so that all your brushes fit into a grid of 8/16/32/64 units.  Equally important is making the exact size of the interior space of your rooms a multiple of a standard prop length.  If you intend to use static props to decorate a room as shown above, the size of the room needs to be very particular.  In the example shown above, the wall section in which I want to fit this row of props is 1344 inches long.  That fits the grid fine as it’s 64*21, but the prop I’m trying to use is 256 inches, which doesn’t divide evenly into 1344.  The props could be extended past the wall, but that’s a sloppy solution that doesn’t always work.

2. Relative scale of objects within a scene

This is pretty fundamental.  You can see a very noticeable difference in texture scale (and polygon density) between the arch and the corner column.  In my mind as I was working on the column and roof elements, the room seemed a lot smaller than it actually is.  Once I got everything together ingame, the jump in quality was very jarring.  This definitely needs to be changed, probably by separating the whole column shape into smaller pieces, and using BSP for the body of the column with static prop decorations on the bottom.

Here you can see another example.  The onion dome is a lot large than I was imagining it, and I think it ended up looking so comically large as to be structurally unbelievable.  The windows at the base are large enough for the player to fit through.  Additionally, the sparsely detailed areas seem even more bland when enlarged, which brings me to another point.

3. Reference material and concept art

Also very fundamental.  The design for the arches was more-or-less lifted from arches in the Mezquita de Cordoba in Spain.  I don’t have any qualms about this thievery, because I’m no concept artist.  That’s exactly why I should lean much more heavily on reference than I did for the corner supports, roof, and dome, which were more or less pulled from nowhere.  I think the difference in quality, especially in the half-assed textures, really shows.

In addition to making custom props detailed and fundamentally appealing to the eye, it’s good to have a general sketch of the level from an aesthetic point of view.  I can come up with passable props if I am inspired by (i.e. steal from) enough reference material, but more complicated tasks like putting it all together with a coherent color scheme are more difficult.  I’d like to blame that on my school’s foundation design courses for their lack of practical, commercially-oriented instruction.  But boo-hooing aside, I need to do more to hammer those things out ahead of time and make sure they look good before moving on.

4. Modularity

Aside from this roof’s aesthetic issues, the biggest problem is that it’s made of two giant chunks.  It would have been four, but lamentably, the Source engine is apparently unable to mirror static props and can only rotate them.  I realized after putting this roof together that it doesn’t do much that BSP couldn’t do, it doesn’t use texture space efficiently, and most criminally, there’s absolutely no context other than this particular building in which it can be used.  It needs to be broken up into smaller chunks, and it would probably be better to use BSP for the top of the plateau so that it can take advantage of lightmapping.

A Summary of My Career Interests Thus Far

Ominous prologue, the early 1990s: My grandfather, Herbert L. Forsythe, Sr., had an Atari 2600.  From as early as I can remember, I was at his house watching and playing Kaboom! and River Raid in what were to become some of my earliest, fondest memories.

My senior year in high school, I had to decide which colleges I wanted to apply to.  The one self-evident rule in this process was to first decide what job I’d like to have, and figure out a good school from there.  I decided I would become a Graphic Design major, because there was money in it and I liked making websites.  Looking back, these decisions weren’t entirely solid, but I’ve always believed in having a concrete career goal despite any doubts, knowing that there’s still time to change paths.

That year, Senior Theology Teacher Mike Bouton invited John Coburn to speak to a few students.  John was an alumnus of my high school and had majored in ITGM at SCAD. (He currently teaches at ITT Tech in Bessemer.)  He talked to us about SCAD and about the game design program, and while I still wasn’t seriously considering ITGM at that point, it’s probably because of Mike Bouton and John Coburn that I’m at SCAD now.  My plan, anyway, was to go to SCAD and major in Graphic Design.

At some point that summer, I realized that graphic design made me want to kill myself.  When I got to Savannah, this revelation was reinforced by completely substanceless foundation design courses.  So I decided I’d major in Animation instead.  After all, I really enjoyed making dumb flash movies as a kid.

Still in my first year, probably sobered by drawing classes and the realization that animation involved a lot of drawing, I figured I probably wouldn’t enjoy it very much.  I had two other options that appealed to me more than Animation: Visual Effects and Interactive Design and Game Development.

VSFX, to me, was all the fun of Animation without the drawing.  I considered going into ITGM, but that wasn’t a real major.  Most of the ITGM freshmen I met chose their major based on the conclusion, “I like to play games, therefore I should make games.”  It was a Collins College major, and I had no interest in tightening up the graphics on level three.  Briefly, I decided on VSFX.

But a short while later, conveniently right before I had to declare a major, I came to a conclusion: There are people who make games.  It is a job that people do. And besides that, pretenses about game development programs don’t mean anything at hiring time.  Bottom line, I had enough self-confidence and enough faith in SCAD to commit myself to ITGM as a major.  Over the course of a year, I had gradually moved toward less established, less respectable disciplines.  But ITGM definitely felt like the right choice, and I don’t regret it.

I still lie when the lady giving me a $10 haircut asks what I’m majoring in, and I don’t like the non-academic “hooray let’s play carcassonne” attitude of the department, but in general my experiences in a year of ITGM classes have surpassed my expectations.  Game development education is still very young, and it will probably be exponentially better 10 years from now (though if trends continue, no one will be able to afford it then anyway).  In any case, I’ve no doubt learned a lot.  One key lesson is that as far as art school majors go, Game Development is no less legitimate than any other.  What matters is what you put into it as a student, and ulimately how good you are at the job you want to do by the time you graduate.

—

Within the discipline of game development, I decided that I wanted to become an environment artist.  I enjoy 3D modeling, and I’ve always been inspired and impressed by the things I see at sites like polycount.  I was also considering level design.  The distinction between the two is that environment art involves designing and creating the 3D art assets to be used in a game, whereas level design is the process of creating the space in which gameplay occurs, placing and scripting obstacles which make use of the game’s mechanics in order to challenge the player in fun and interesting ways.  In a way they’re closely related, but they require very different skill sets.

What drew me to environment art is that it requires a lot of technical skill and artistic ability, and those are things that you can easily see.  If you want to demonstrate to someone that you’re a good artist, you show them your portfolio and they can instantly determine whether you’re good at what you do.  In level design, there is no such convenient metric.  Fun is a more abstract concept, and you have to actually play through a level to know if it’s worth anything.  Also, any idiot can figure out how to put boxes together to make a game map, but proper modeling/texturing/sculpting has a steep learning curve, and it seemed like a good idea to have successfully breached that barrier to entry as proof of my ability.

After a couple of quarters in ITGM, though, it didn’t take me long to realize that it wouldn’t pay to base long-term career goals on frivolous assumptions like those.  I’ve been trying to feel out level design and environment without too many preconceptions.  Lately, one thing has really tipped the scales toward level design.  I’ve been working on a single-player map for Half-Life 2.  It’s been a whole lot of fun to create a world and come up with inventive challenges.  Last night, after spending all day working in Hammer, I realized that it was 4am and I hadn’t eaten in 10 hours.  I haven’t experienced that feeling in years, and I think it’s a true indicator of where your passions lie to see what completely absorbs you and makes you lose all track of time.

I still really enjoy environment art.  If I hadn’t taken such a circuitous route in deciding on a major, and if it hadn’t been for excellent foundation drawing classes, I probably wouldn’t be anywhere near as competent an artist as I am.  There’s still plenty of room for improvement, and I plan to continue.  But as of right now, with another quarter or two left to change my mind, I can’t help but see level design as the most appealing career goal.

Maybe the very reason I’ve been so easily drawn to level design is that any idiot can put boxes together and make a map.  There’s no massive barrier to entry, but that’s an altogether good thing because it allows a level designer to block his ideas out quickly.  There’s a level of challenge and complexity far beyond blocking out a space and throwing in NPCs.  Creating a convincing world that supports gameplay systems, scripting events and NPC behaviors, optimizing levels to run efficiently, and making levels fun are all things that I can get behind and that I enjoy immensely.  I’ve come to realize that there are plenty of things that separate good levels from bad, even if, unlike an environment art portfolio, you can’t tell just by looking at them.

Real-world applications of fifth grade math

I love end-of-quarter spreadsheets.  The fun thing about the F/D/C/B/A system is that if you’re sitting at a low B and it’s impossible for you to get an A, you only need to maintain your low B.  If 40 points out of 100 will maintain that B, anything more than 40 points will, gradewise, be wasted.  In my first year I needed a 42 on my final project in Drawing For Storyboarding to maintain a B (an A was impossible).  Realizing this, I lowered my standard of quality and just focused on getting the project done passably, but I ended up getting a 92, which was my highest grade in that class.  It kind of pissed me off that I got an A.

Of course, now that I’m in classes that are both enjoyable and extremely relevant to professional growth, I still put forth 110% in my major classes even when I can afford to do less.  But for work-intensive liberal arts classes like Psychology, it’s a nice relief to find that you can safely neglect a 9-page writing assignment in order to focus more energy toward those important major classes.

Spreadsheets are fun.

The blood of patriots and tyrants: It’s a natural manure!

Very recently I’ve started keeping a bookmark folder on my favorites bar for random notes.  The idea is that when I find something interesting online, I add it to this folder instead of letting it sit in my short-term memory for three minutes before it decides to leave forever. (I’m not sure why it’s never dawned on me to use bookmarks.)  From the 50 or so sites I’ve collected, here are the few that I think are worth sharing.

Games

Deus Ex – The Nameless Mod (SA) – On the plus side, this mod is based on one of the best games ever made and is apparently pretty good.  On the down side, it has a ridiculous plot based on a Deus Ex fan forum.

Valve Publications – I cited one of these papers for an essay in Survey of Interactive Entertainment.  I love Valve for their in-game developer commentary, and for generally advancing the medium by realizing it’s OK to talk in detail about games that have been released.

Warren Spector Master Class – An absolutely brilliant educational resource.  I’ve only seen a few of these lectures due to lack of time, but I’ve learned a ton from Warren Spector and the professionals he invited to speak at his UT class.

LoZ Parallel Worlds Let’s Play - These massive romhack projects always amaze me because of the amount of work from one or two people that goes into squeezing more content out of beloved childhood classics.  Unfortunately, all that work doesn’t guarantee a fun game.  I haven’t played parallel worlds, but from the LP it looks like one of those masochistic games where you have no idea where to go 90% of the time.

IGDA – GDC Student Scholarships - Attending GDC is the holy grail of the aspiring game industry professional, but it’s expensive as hell.  A free pass is an opportunity that can’t be passed up.  If that fails, I hear volunteer applications open up around November.

SCAD TV – A few of the lectures from GDX were posted here.  I’ve been meaning to get around to watching the ones I missed in person.

Elitist Jerks Forums – Many of the blogs I read cite EJ as an important resource for understanding game design.  I’m afraid that if I keep up with WoW, I won’t be able to resist reactivating my account.

Belan the looter’s episodes – Reading this site briefly made me want to play UO again.  UO was wonderful fun back in the day for the freedom it offered.  Unfortunately, it was fun, just like the radio was a genuine home theater experience.  MMOs having come as far as they have, you just can’t go back.  Even with all the flowery nostalgia that tricks me into thinking that being murdered and looted on Ethics’s doorstep was the most fun I’d ever had, I just can’t find it that fun anymore.

Educational

Academic Earth – This site is basically hulu for online video lectures from various universities.  If I had all the time in the world…

Free Foreign Language Lessons – If you think of life like Metroid, knowing only one language is like getting the charge beam and calling it quits.  You can go to Brinstar, but you won’t get much out of it without the Varia suit.  Learning a living language “unlocks” a huge part of the world to you.  Nota a mi mismo: Retén español.

Environmentoring (ConceptArt.org) – A series of tutorials in a free, forum-based class structure.

Middle English: Languages of the World – These videos are a pretty interesting look at the evolution of the English language.  Watching some of this guy’s videos also provokes mild Alabama rage at his fancy book-learnin academic attitude.  A lot of people write the way they speak, and the result is a mess of unclear writing.  On the flipside, I don’t understand people like this, who speak the way they write.  It makes you come off as stiff and condescending when you have to pause and let the person you’re speaking to look up a word in his pocket dictionary.

cannedmushrooms’s Video Lessons in Zbrush – Some charitable fellow has made a series of free video tutorials for ZBrush.  ZBrush is very important to have a grasp of, and it’s also a complete mystery to me, so I’ll have to check these out over the summer.

Student Illusions About Being a Game Designer – I wish to God that SCAD would hand a hard copy of this article to every entering student who’s considering ITGM as a major.

Random

White movement (Wikipedia) – Everybody loves the Soviets (except those oppressed or executed by the Soviets), but the Tsarist White Army never gets any love.  I guess the Bolsheviks did a good job of taking it to an undisclosed location, shooting it in the back of the head, and shoving it down a well with a hand grenade chaser.  The Russian Civil War is an interesting bit of history, and it’d be cool to see a work of art where Tsarists soldiers do something other than shoot civilian infants on a giant staircase.

Requiem for a Harlequin (Wikipedia) – I’ve always known David Allan Coe as the guy who wrote all those racist country songs, but apparently he’s deeper than that.  This is a rock album about growing up on the streets that he did before he starting playing country music.

A Night on the Town – I heard this show on 90.1 WABE Atlanta heading back from Birmingham to Savannah, and I made a note to look it up online.  It’s nice when public radio offers something other than classical and space music.

Tsar Cannon – The largest and most ridiculous cannon ever built.  Might be a fun ZBrush project.

Living in Three Centuries: The Face of Age – A collection of portraits of people over the age of 100.

Hank Williams III – Ramblin Man – I never knew that there was a grandson of Hank Williams running around and performing music, but here he is.  His act is one of those genre mashups.  They call it cowpunk.

House (Hulu) – The last few episodes of House have been fantastic.  I really enjoyed the Mos Def episodes, and the plot twist federally mandated by Barack Obama was handled very well.  It’s just gotten better from there.  I love the surreal stuff, like the season 2 finale.

You wouldn’t believe how many “I’m on a boat” references I had to endure while making this

Two quarters ago, when I was in CMPA110, I posted my projects on this blog.  I’ve conveniently skipped showing my projects from ITGM130, Digital Design Aesthetics, because they’re boring and not worth writing about.  This quarter I’m taking ITGM240: Modeling, Materials & Lighting.  This class, almost halfway through my four years, is really the beginning for me.  My long-term career goal is doing environments for games.  It’s what I really enjoy, particularly modeling and (oddly) laying out UVs.  So this class is where I’m pouring all my effort this quarter, which is tough since I have two other classes that require as much work, if not more.  The first project was a WWI Springfield rifle.  I’m not bothering to show it because it’s an exercise from a book that hundreds of people have done, it’s not modeled very well, and it doesn’t have a texture because I didn’t know when it was due (luckily, I’m able to resubmit projects in this class).

The second project for MML was a lot more open-ended.  We were to design and model a complex object.  Since I have laying around a folder of whaling reference images that was begging to be used, I decided to make a whaling ship.

Concept rendering is something I’d really like to improve on, but there it is.  There were a lot of detail sketches of different parts and props, but unfortunately most of them didn’t make it into the final product.  In fact, toward the end I realized I couldn’t finish everything, and the focus shifted a bit.  It ended up being a blocky model of a harpoon gun with some pretty elaborate background scenery.

I had two weeks to work on it, but I also had a lot of work to do for other classes.  And besides that, unwrapping that harpoon gun took about six hours, and there was a lot more than that to be UV’ed.  But that took a lot of time mostly because I was unaware of Move and Sew and hadn’t worked out a solid process for UV layout.  Looking back, the whole thing was a huge learning process.  I came into the project knowing how to use Maya pretty well, but the experience of making this ship filled in so many blank spots about proper workflows, practices for efficient modeling, and other things you can’t learn without experience.

Some of the things I learned through failure while working on this project:

1. Proportion is important, starting from the very earliest concepts.  My drawings had no scale reference, and while modeling most of the ship I just cloned simple boxes around the scene to serve as human-sized reference objects.  But a box is very ambiguous, so I ended up adding heads and arms to them later on and having to rescale things, but I still don’t think my boat would be a properly-proportioned whaling vessel in real life.  I’m paying more careful attention to scale in my next project.
2. Consider the scope of your project very carefully.  I ended up wasting a lot of time modeling and laying out UVs for part of the ship that I didn’t have time to texture or properly detail.  It’s good to aim high, but make sure that 80% of your goal will still be presentable.  Luckily I was able to focus on the harpoon gun and leave the rest of the ship out of the final render, but it didn’t feel good to jettison all that work.
3. Consider your model’s context, even if you have to make one up.  This was just a modeling project, but it would have helped to establish from the beginning a game engine, an art style, and a context under which the object would appear in a game.  A boat that the player walks on is far different from a boat that the player sees in the distance.
4. Within reason, don’t undershoot the polycount.  This one may be debatable, but it’s easier to remove edge loops than to add them.  For me, this went hand-in-hand with the previous point: from the beginning I should have considered that the original hull was far, far too low-poly for such a large prop that the player would walk on.
5. When laying out UVs, minimize seams in large, highly visible areas.  For the hull I made planar projections on the port and starboard sides, and then made separate projections for the bow and stern.  The sides looked great by themselves, but there was no way to avoid a giant, ugly seam between the bow and the sides.  This configuration made it very difficult to paint out this seam.  It probably would have been better to put the seams on the sides where they would have been much easier to paint out.
6. Reference is important, and so is making concepts based on that reference.  The shape of the hull was somewhat stylized, but it was based on photos of similar-sized ships.  The harpoon gun was based on reference (though, going along with point #3 and establishing an art style, I wish I had made it more stylized).  The cabin, bridge, and mast are all completely fantastical and almost entirely made up without reference.  It definitely shows in the noticeable disconnect in the scale, detail, and general aesthetic of those different parts.

I’d like to go back and redo most of this, maybe during the break.  For now, though, I’m working on the third project, an interior scene.  I’ve got 11 more days.