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).

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.

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.

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.

We are not to expect to be translated from despotism to liberty in a featherbed.

poop