Gold Mining

Been pondering an idea for a Flash/ActionScript game based on gold mining. Inspired by a recent trip to Goldfield ghost town, the game would be a social application with the object of building up your claim to increase your production of revenue. This image is a render of a few test models to sort of fix in my head the tone and feel of the game. I've been looking into the details and technicalities of Facebook application development, with an eye toward deploying this thing.

Panning map

Been wrapping my head around ActionScript. Got a simple map up and running. Not much to it now, just a repeating dirt tile and a bouncing black ball for a testing map object. You can grab the map with the mouse left button and move the mouse around to pan the map, and that's about it so far. But I'm getting there. You can take a look at the thing here if you are curious.

Simplify, simplify, simplify

An inconvenient truth about myself is that I always reach for more. Witness this blog, which began as an attempt to follow the design and construction of a small game, harking back to old school RPGs. The game has now mushroomed into a fully 3D monstrosity. So far, it looks pretty sweet. Dynamic, 3D lighting, randomly generated and placed geometry, I've re-incorporated the skeletal animation system I built a few years ago for component-based animations allowing paper-doll player equipment setups, etc...

It's gotten out of hand.

I started with a small game because I wanted to focus on making the game, not on building yet another gigantic mass of engine spaghetti code. I can continue for months, if not years, mudging around the code base, making changes, fiddling and farting around... and I'll end up with a pretty engine that falls short of production quality, and nothing in the way of a real game. It's the usual cycle.

So I'm taking a step back, and officially dropping the 3D monstrosity. I wanted a small game, so I'm going back to a small game. Toward that end, I've begun fiddling with ActionScript 3 and the Flex 3 SDK. It's been fun, and the natural limitations of the Flash platform ensure that I won't be ballooning this thing into some huge 3D atrocity for which I lack the time and patience to actually create a usable game for. Plus, I have it in my head to begin developing a series of smaller, casual-style games, perhaps for FaceBook and perhaps for merely standalone.

So pardon me while I regroup, and I'll try to get some updated screenshots of my efforts in place.

Playing around

I've been getting rather far afield with what I initially planned for this thing, but that is typical for me. Here is a new image. Couple things about it.

1) It's a fully 3D version of the procedurally generated mountains I made for the 2D top down overmap. Same exact mountains, slightly modified so that the generation routine exports a mesh geometry as well as the color map.

2) I'm playing with the idea of doing the overmap in this style: 3D, with perspective.

3) The above test was done with the Irrlicht engine. I looked at the engine several years ago and it roused my curiosity. I've been thinking of dumping a good part of my code base in favor of a 'finished' engine such as Irrlicht, due to the rather incomplete nature of many of my systems. When it comes to the boring details, I'm not a very thorough implementer. I'll code just enough of a skeleton framework to have it come back and bit me in the ass when it's time to refine the project and make it more robust.

However, I do need to implement some things if I decide to use Irrlicht. Due to the nature of my levels (randomly generated, pieced-together meshes) the existing scene node types (particularly their Octree implementation, which is weird) are not suitable I'm working on a quad tree structure which should be sufficient for my needs, since it will essentially be a 2D game in that it won't have Z levels or fully explorable structures or anything like that.

Still not 100% decided about anything, though.

3D Test

evolutional is sort of talking me around to doing it the fully 3D way. It is a lot simpler, although there are things I don't like about it. My modeling style tends to be sloppy: lots of verts, probably way more than is needed to structure a scene. Which is why I usually render a structure then map the render to a crude, low-poly shape (like the sides of an isometric box or cell, as I've been doing). With that method, the detail of your geometry doesn't matter since it's pre-rendered, but getting seams and edges to line up, etc... takes some work.

Doing the objects fully 3D, though, I don't have to worry about a lot of the things, but I do have to worry about the complexity of my geometry. I also have to completely overhaul my lighting system. In the attached screenshot you can see a render test in progress, a section of (placeholder) cliff on a nasty looking background. Just working out the kinks and details of the Blender->Game pipeline, and playing with some lighting options. The above is statically lit, no dynamic lights in play. In fact, in-game lighting has been disable since the 2D grid system I was using doesn't play well with 3D geometry. It looks bad. There is also some cracking between a few of the wall segments. That was my foul up. 0.9999999999 does not equal 1.0, and the GPU will prove it to you every time.

The good news is, though, I have a Wavefront .OBJ loader up and running, so exporting from Blender is a bit easier.

Graphics Asset Pipeline

I'm in the midst of hammering out the asset delivery pipeline and storage system for the submap isometric graphics. Part of the reason I had initially elected to do a straight top-down game was the trouble I have with creating the graphical assets in isometric games. I've worked out a few techniques, though.

The games I make are typically always randomly generated, so I need to structure my graphics in sets of tiles that can be combined together to create any arbitrary layout or section. Hence, the creation process has some pretty tight restrictions. In this screenshot, you can see a typical view of Blender as I work on a particular graphic set.



I construct a special staging .blend file with planes to represent the tile nodes of the map, then create the objects to be rendered on top of the planes, using the planes as guides for spacing and positioning. In order to create the seamless effect, the objects need to be aligned with copies of themselves in adjacent tiles. Then, a tall sliver or slice of the scene is rendered:



If I did everything correctly, the slice can be used as a piece in the larger set, tiling next to itself as many times as are needed:



Of course, this is an extremely simple example and in reality it gets more complicated. The above example renders a narrow (64 pixel) slice. However, not all structures will repeat that frequently, so different sets need to be made with more pieces to cover a larger area. Also, corner pieces need to be made to tie in all the flat side sections. And with simple, regularly repeating geometric shapes like these arches, there are few gotchas. However, when doing irregular shapes like a cliff face or jumbles of boulders, you need to watch out and be very careful with your positioning, lighting, and rendering or ugly seams can result which destroy the illusion.

Isometric

The switch to isometric, engine-wise, is as simple as changing a camera setting. There are some minor complications with texture filtering, easily solved by rearranging the way the assets are stored, not a big deal. I am considering doing the submaps in isometric. They are where all the action takes place, and things aren't as weird as a top down.

It's either that, or switch the story and setting of the game itself to one that favors a top down perspective more. The biggest gripe I have is that humanoid figures are so hard to distinguish in top down, since most of the distinguishing features are hidden. However, if I were to switch to focus on a different set of races/civilizations/whatever rather than humanoid, I could pull off the top-down much more stylishly.

Awhile back I had the idea for a game called Drone, wherein you play a drone member of a hive of genetically altered insects. You advance in rank within the hive, and correspondingly advance in power and self-mastery until you could at last break away from the hive mind and start your own hive.

The thing I like about insects is that they look good from top-down, and are easily distinguishable from one another. The thing I don't like about insects is that making graphics for their hives and nests is very difficult for me. All the dripping ichor and ooze, all the gristly legs and antenna, etc... I don't do so well with that sort of thing. My dripping ichor tends to look like grey blobbish things, and not ichor at all. Also, so far I've held somewhat to the old-school RPG look and feel (mountains/forest/grass/water, fantasy-setting type stuff), and I'm not sure how well it would jive with the whole insect thing.

I could always resurrect my old Golem story. Many years back I was working on an isometric game called Golem, wherein you play the part of a magical construct working to save the last remnant of the human race from extinction by other golems running wild. The beauty of that idea was that the constructs were often bizarre, and typically not humanoid in nature. Many of the golems I conceptualized would work as well in top-down as in isometric.

At any rate, I have begun work on the 'action' parts of the game. To crudely paraphrase Gamasutra's post-mortem on Diablo 2, I need to get a guy moving around on the screen and hacking at monsters. Whether in top-down or isometric, monster hacking is monster hacking.