The Ancient Games of the Rampant Coyote, part 2

Posted by Rampant Coyote on March 23, 2011

Here are a couple more old unfinished games from my distant past development efforts that I managed to salvage somehow. Unfortunately, many others have been lost – probably forever – including a few of “finished” games (never publicly released, though). But here are two more that I managed to dredge up and actually run:

The first one never quite had a name… I think I told people it was called War of the Superpowers. It was inspired by games like Master of Orion, Civilization, and the boardgame Supremacy.  The concept was that you started out in control of a fictional superpower in a time period or tech level approximately that of around 1900 AD. The goal was, of course, to take over the entire world in a turn-based clash of arms and technology.

The maps were randomly generated on a grid, using names of real-world nations, but I deformed the corners of the grid so it looked less… well, grid-like. It still didn’t look “natural” or anything like that, but it looked more interesting and you could always tell which state bordered another.  The gray states are independent nations, and would never ally together, so they were easy pickings for a superpower nation. The easiest way to add them to your superpower was through military might, but that would always damage their resources. But they could also be diplomatically enticed to joining your nation – but that was generally more expensive and took longer. However, if threatened militarily by any superpower, they’d be more inclined to be absorbed. Thus it was always dangerous to threaten a superpower’s “buffer state.”

Each state had a surplus or deficit of … stuff. As a superpower nation, they were all combined together as a whole. You could spend time and money developing a state’s resources, but there were always theoretical limits. You could perform an “assay” command on a state as a sub-action of resource development at some cost, but the results were always a very rough estimate. Perhaps too rough, as the maximum in the screen to the left is actually below the current level. Did I mention this game was never finished?

I think I’d envisioned each turn being the analog of approximately a quarter-year, but I didn’t want to literally display that on the screen, so I kept it abstract with turns. Each turn you could take a certain number of “actions” – I don’t remember whether it was always four (doesn’t seem to be), or if it depended upon how many states you controlled, or how much food supply you had.

I’ve always been a sucker for technology advancement in these kinds of games. I’m always the guy who does all the research to max out my tech tree before anybody else. Or get as far as I can before getting wiped out by my technologically inferior but militarily quite overwhelming opponent.  It doesn’t matter if my ship is twice as powerful as theirs if they have ten times as many ships. But anyway – I put technology in the game. Apparently I didn’t make it a tech “tree” so much, as you can research a space shuttle before developing aviation as a viable technology. Go figger. But hey, I have a minimalist beaker in the background of this screen representing SCIENCE! Anyway, the different technologies would help your nation as it grew. For example, energy conservation would decrease your population’s energy consumption, thus increasing the energy surplus or decreasing the deficit.

This game was also included on my portfolio disk when I was interviewing for my first game job. I don’t think it won any company over, but I did do the show and tell in my interview with it.  I think one company was impressed with my work on Netrunner: Pawn’s Gambit which I blogged about yesterday. I think that  SingleTrac was most impressed by another game I no longer have called Armorena. Armorena was a 3D game using my ugly flat-shaded poly rasterizer thich could be played multiplayer over a null-modem connection. I’d written it for a project in my Computer Networking class my final semester in college.  The game sucked.  Horribly. But it earned a decent grade, and the guys at SingleTrac thought it showed I was familiar with 3D programming in an era where you just didn’t have off-the-shelf game engines or APIs… I had to write it all myself.

After I left the games biz about six years later, I had become a big fan of EverQuest. In order to keep my game development skills sharp, I thought I’d make a Direct-X based 3D MMORPG. For fun. I didn’t get far. But I did have some interesting ideas on scene management that I still think would work. Anyway, I made a game engine which I called “Enguard” and was working on an MMORPG called “Here There Be Dragons.”

I was using no 3D modeling package, so all my models were created in a text file, by hand, vertex by vertex. Yes, it is exactly as stupid and painful as it sounds. I’d not done any research on shareware or freeware modeling software… I was just familiar with expensive, premium software we’d used at work at Acclaim and SingleTrac like SoftImage, Maya, and 3DS Max. So this is what I got. I particularly love the spherical goblin up there. I wrote code to generate the sphere and UV mapping.

I borrowed textures and art from DirectX demos and from the game Vampire the Masquerade: Redemption. As you can tell, my dungeon-building skills haven’t improved much over the last decade.

My approach with the different areas in the game was based on some messing around I’d done in text-based MUDs and even text adventures I wrote back in the 1980s. What if you divided up a world into “rooms” with neighboring connections. For a landscape, for example, a single “tile” of terrain data (of whatever size) might represent one “room”, and would be connected to four other “tiles”  to the north, south, east, and west. Those would be direct connections. The corner tiles would be indirect connections, one connection distant. With an actual segment of a dungeon – a room or an area with a small collection of rooms or hallways – you could do the same thing, more literally.  Now what if the game only kept loaded some high-level information for all of the rooms, and the geometry detail for only your current “room”, and its direct and one connection distant indirect neighbors? I think nowadays that sort of approach is pretty common (but with improved technique), but at the time it was an answer to the long load-times and dealing with AI behavior navigating complex geometry (now their movement would be abstract node-crossing until they got “close” to a player).

I never finished Here There Be Dragons, either.  After playing around with it a bit, I realized that there was no way I was ready to tackle even a scaled-down MMORPG. But I’d already done a lot of work on a custom 3D engine, plus some networking code. The “Enguard” engine was nowhere near ready for prime time, but the technology was already there.

And here the story once again has a happy ending.

Instead of making an MMORPG, I thought smaller, action-style games, multiplayer (to take advantage of that networking code I’d written… though ironically I ended up replacing all of it) using the engine. And that was where Void War was born.  I had no idea of what I was doing – I was a game programmer with illusions of being a designer who was absolutely clueless about indie games – but it was a great learning opportunity. So that dungeon up above ended up becoming a multiplayer Newtonian-physics based tongue-in-cheek space combat game.

The other games got me a job in the videogames industry. But Here There Be Dragons – indirectly – got me started as an indie.

Filed Under: Game Development, Retro - Comments: 7 Comments to Read



top