Commonsense IP rights
Psychochild says it better than me.

I can't find anything to disagree with. Protecting IP rights should be a high priority with our laws - but now we alternate between ineffectual and draconian. The middle ground - the place occupied by artists, authors, and the working-class joes who pay with their sweat, blood, and tears to bring something that will hopefully profit the world (or at least entertain the world) - is turning into a desolate wasteland in a battlefield between pirates and big business.

It's sad, but it's nothing new.

Labels: Biz

- posted by The Rampant Coyote @ 4:27 PM (Permalink) 0 comments links to this post

 
Paying the Bills Takes Priority.
Man. Financing a game-development habit by working a responsible day job sure sounds like a great idea sometimes. Except when you are working 60-hour work-weeks and pulling all-nighters to meet a deadline. Then it's not such a good deal. I've had precious little time to do anything this week. I had a tough time dragging myself to doing coding at all, but I still demanded of myself to do at least a little game development work most nights.

So I'm not going to count this week against my projected development time based on that little metric I talked about a few days ago.

So I concentrated on the art stuff. I'm still no artist, but I find it's a relaxing change of pace. All I really did, actually, was hunt for some nice textures, including some reference photos, and a better skybox. I also played a bit fog in Torque (it's behavior is a little... indeterminant... with the editor). A found some nice skyboxes from Adam deGrandis that he had made freely available, as well as Matt Jones' Sharp Tree Pack (definitely going to consider licensing these - they are a good bargain at $25!) I put the trees on Torque "Shape Replicators" and let it randomly sprinkle them throughout the terrain.


I'll keep scoping out free / cheap content that's out there - the amateur / indie community has some great bargains available that are of reasonably good quality, if you are willing to settle for non-exclusivity. And assuming you can find it.
- posted by The Rampant Coyote @ 10:27 PM (Permalink) 0 comments links to this post

 
A Metric for Scoping Games?
Well, it's Saturday, and I'm stuck at the office today on about my sixtieth hour this week trying to make a so-called RAD (Rapid Application Development) tool do stuff that was never intended by the team that designed the thing. Whether that's their limitation, or my own, I don't know. But I needed a short break and I wanted to talk game development stuff, so here I am.

I was re-reading an article by Phil Carlisle a few days ago (in response to a thread on the GarageGames forums). Something really struck me. While the numbers thrown around by Phil and Dan MacDonald (in the comments) aren't necessarily definitive, they are a pretty solid rule of thumb if you know what you are doing and aren't at the fast-moving point in the learning curve. That means for every week you spend prototyping, you'll spend two additional weeks getting it "feature complete" - and then two months polishing it and getting it ready to release. So you can pretty much estimate your dev time by the amount of time it takes to prototype the game - or, working backwards, you can define the scope of the game by taking your total dev time, dividing it by twelve, and then scoping your prototype to fit within that time.

Of course, there are variables. At SingleTrac we spent about three months getting prototypes done for our first games that had only a 1 year development horizon. So that's only a 1:4 ratio. A lot of those three months were spent characterizing the machine, staffing up the dev teams, and getting over the early-learning-curve stuff. We had probably twice the team size during development as we did during prototyping and early-engine-creation... so that would bring the ratio from 1:4 to about 1:8. Not quite 1:12, but halfway there. The learning-curve stages could account for some of it. And, arguably, the compression showed - SingleTrac never had a reputation for having extremely polished-looking games.

Void War took about 1/6th of the time to prototype instead of 1/12th... but I also ramped up the amount of time I spent on the project significantly during the latter third of development (from about 10 hours a week to 30+). So if you consider the last six months to be worth three times the value of the first twelve, you get a total development time of 30 "10 hours-per-week months." 3 of those spent prototyping... That's a 1:10 ratio instead of 1:12, but still dang close. HOWEVER - I also got some additional help developing content and programming the launcher during the latter half of development. Bingo. Unscientific guesstimation could bring that ratio to about 1:12. So Dan's numbers hold up.

So I think we have something approaching a true, honest-to-goodness metric for scoping games. Something hard to think about - especially for ME, working on my current projects. While I'm breaking a few rules with this game design, deliberately persuing some methods of achieving larger scope along one axis by reducing scope along another... it doesn't make me immune. Does this apply to triple-A retail games as well? Maybe, though if anything I'd say the escalation of production qualities means an even smaller ratio.

And moving on to something different, with pictures:

I think my "prototype" barn turned out pretty well, as a learner project. I don't know if the 1:12 ratio applies here (I hope not, or I'll be spending about 12 weeks on every one-room-sized interior in my game, and I'll be screwed!). It's not professional quality, and the final version will have to have things like a ladder, doors on the stalls, and lots of clutter - like hay bails and maybe piles of fly-attracting dung (phew!) And I need to figure out how to get rid of the "sneaky ninja lightmap-leaks" that show off certain edges between polygons. But for creating a simple environment for testing out gameplay, I think it'll work just fine.

Labels: Game Design

- posted by The Rampant Coyote @ 2:18 PM (Permalink) 8 comments links to this post

 
Changing Hosting
You may have noticed the site has been up and down a LOT the last week. Our hosting solution is having trouble with the load, and the server is hard-crashing on a regular basis. So we're moving. This has been coming for a while now, but it's going to be painful for the next few days.

Hopefully by next week, everything will be cool and stable.

In the meantime, I've got an article up on GameDev.Net - that's part of the reason we've had the increased traffic. It's about the creation of Hackenslash - a game built from scratch in a single week.

http://www.gamedev.net/reference/business/features/gameinaweek/

If you want to check out the game, you can grab it from a cached link right now:
http://download.rampantgames.com/hackenslash.zip

Anyway, things should be back to normal in short order.
- posted by The Rampant Coyote @ 7:34 AM (Permalink) 0 comments links to this post

 
Raising a Barn!
So I've moved on to something new. Same game, just a new aspect of it. The opening cutscene is far from finished, but I'm now convinced that there's no significant technical risk to doing it in Torque, and I've learned way more than I wanted to about how the Torque camera operates. I've also learned a little more about animation - the tools, and how it operates in the Torque engine.

Next, I'm developing a very simple level for gameplay to happen. Part of my second "technical assessment" is to have an indoor environment. And I really want to take a crack at level building. Develop latent talents or something. Or at least be able to converse with level designers and not sound completely ignorant. So I crack my knuckles and get going.

Well, not quite. I'm actually a little terrified - I'm not entirely certain where to start. I have dabbled slightly in Quark - I used it to create the roads in the cutscene, and a few months ago I built something resembling an empty concrete bunker, but without so much detail. I created a cube, elongated it, hollowed it out, and then used another brush to subtract out a doorway. Woot. I decided that my first project is going to be a barn, since that's relatively simple, and if I do a sloppy job of it, it'll just make the level appear more "rustic" or "authentic," so it'll all be good. Maybe.

I started by scouring the Internet for photographs of barns. A Google image search gave me roughly 20,000 pictures. There is also a dillapidated barn I see on my way to work every day. One wall is half-rotted away, so I can catch some glimpse of what the interior looks like. I also watched the DVD of an old TV show with a nice barn set design. If there is such a thing as a "typical" barn design, I haven't discovered it - they are a million different variations. I think the Amish have it down to a science with their weekly barn-raisings, but I don't think they ever had computer games in mind.

Anyway, after way more research into barn design than any human being who doesn't have a degree in Agricultural Management should ever have to go through, I begin building my barn, from the ground up. My default texture is concrete. I'm really going for that bunker-look again. When I'm done, I change a couple of textures around, making liberal use of Mayang's Free Textures, the GIMP, and the Seamless Texture Generator. My initial results, an hour or so later, show promise - but once again I have something that's more of a concrete bunker than a barn.

My next step is to retexture things, and fix some undue penetration of brushes. I'm still learning this stuff from the ground up, and I'm not entirely certain what features are supported by Torque's Map2Dif exporter. So I am keeping it really basic. More playing with textures follows, as I try to disguise where the polygons are actually joined together.

After I get the textures looking something slightly less like an unstocked bomb shelter, I begin adding some detail. The barn really needs some support beams in place, so I work on those. The initial effort to throw those into Quark, kinda-sorta lined up with the walls and roof they are supposed to be holding up, take very little time. I feel inspired about how quickly I'm getting the hang of this stuff. It's the last time I feel like I'm making great progress.

When I export all this to Torque, I fly around my newly-modified CinemaCam (now with smooth human control!) and note that all is not well in the barnyard. There are two problems, really. The first is that I'm getting ambient light from outside in my barn. That's not a big deal, except I explicitly set my portal so that it wouldn't transmit ambient light. The second is that some of my support beams, which were so nicely and seamlessly joined together in QuarK and its OpenGL 3D view, have been cruelly separated - and are, in fact, sinking into polygons that there were supposed to only barely touch. Something is not right!
Things get wiggy when they are at non-ninety-degree angles, which makes me think (as a programmer) that there's some kind of precision problem going on. I don't really solve the problem - I just make it go away (temporarily) by snapping things to grid. You guys who know QuARK & Map2Dif, please give me a hand to know how to solve this, because it's rearing it's ugly head in some other areas. (In fact, I can just use some general advice across the board, because I'm making lots of newbie mistakes and I'd like to learn the ins and outs of this the easy way if I can - but the documentation is sparse).

The ambient light thing is a bigger problem, but it turned out to have a similar solution. I first started playing with the portal - toggling it's ambient-light-blocking flag on and off. No dice. I checked the "Search for Holes in map" function in Quark to see if I'd left any gaping holes in my structure, but Quark reported no holes found. So if there WERE holes, they existed only in the DIF file (or Quark was being buggy). To make sure I could tell the difference between ambient light and none, I turned up the sunlight outside, and I made the interior light a very simple point light. I'm using John Kabus's excellent Synapse Lighting Pack, which just makes the lights in Torque just [i]SHINE[/i] (pardon the pun). My starkly-lit barn is now extremely obvious if it's properly unlit from the outside. And my crappy modeling looks so much better in the dark.

The next thing I did was a trick I learned from watching too many Gangster movies - I encased my problem in concrete. Since I'm so good at modeling big, boring, concrete [b]blocks[/b], I just created a whole bunch of them to hole up my barn inside a concrete "dock". The nice, rectilnear shell effectively blocked out all ambient light. The concrete blocks engulfed the edges and corners of my barn, and sure enough, the barn was now dark except for the rafters. Except for Fluffy the Orc, who glowed in the dark.

My trick was to move, reshape, or delete the concrete blocks to expose a limited area of the barn at a time, and see if it remained dark. If not, I knew my problem children lay within the exposed area, so I could focus my search. I also played with the positioning and angles of the concrete blocks a little bit, to see what conditions would cause them to let the outside ambient light in. Yes, I'm thirty-six years old, and I'm playing with blocks. It's good to be a game developer!

My technique works, though maybe not as quickly as some tried-and-true techniques the experts can now inform me about while they mock my newbie-ness. I find that while having brushes that are flush against each other works fine if they are at nice, neat, 90-degree angles, things get sloppy when they are angled a little less cleanly - probably due to some loss of precision in their transition through Map2Dif or Torque. Whatever the case, it pays to be a little sloppy in return, to make up for the precision-loss, and have the brushed interpentrate a little. There's probably some terrific tool in QuARk for making sure brushes are perfectly aligned within a group without the dangers of precision loss, eliminating unused faces, etc. And I'll figure that one out right after I post this blog and enshrine my ignorance for all to see. But for now, that was my trick to making it work.

The end results? Well, I'm not done yet - there's a LOT of detail work left to do, and the barn is missing things like stalls, hay bails, etc. But I think it's looking pretty nice for now. It's not going to make people cancel their Unreal Tournament 2007 pre-orders or anything, but I think it's a good start for a guy for whom the term "Programmer Art" is actually complimentary.

Jay Barnson
Rampant Games
http://www.rampantgames.com

- posted by The Rampant Coyote @ 11:51 PM (Permalink) 2 comments links to this post

 
Cinema-Cam!
Well, I'm almost done with another one of those ridiculous Black Triangles - in this case, I'm reinventing the wheel in many ways, but hey - it's my wheel, and it works.

In this case, I'm working on a cinematic camera. I wasn't too happy with the base camera functionality in Torque, and the Advanced Camera had some really weird bugs in it - and it still didn't meet my needs. I needed a camera that was appropriate for doing cutscenes - smoothly moving around a scene, performing slow automated pans - slowly "autozooming" in and out with real zoom (Field-of-View) behavior. And of course sometimes "cutting" between targets.

Because I'm working on a single-player game, making certain the camera is server-driven is unimportant. Especially since that can introduce the jitters. I took advantage of the fact that it's a single-player game and made some optimizations that would totally break in multiplayer. I left the server's control of the camera as simple, high level commands - like:

%this.camera.setNewTarget(%this.AIPlayer2);
%this.camera.setSmoothPan(2.0);

Which tells the camera to smoothly rotate to face AIPlayer2 over the course of 2 seconds. There's also commands like:

%this.camera.setZoom(60.0,3.0);

Which tells the camera to zoom in (or out, depending on your current field-of-view settings) to a sixty-degree field of view over the course of three seconds. The client handles the slow-zoom and interpolation. This is actually really impressive in action, as it gives the camera a much more organic "feel" to it.
You can combine the behaviors, too. Here's the "before" and "after" shots taken about four seconds apart, as the camera is zooming from a 90 degree FOV to a 30 degree FOV. Simultaneously, the camera moving backwards away from the car (but not as fast as it is approaching), and of course staying focused on the car as it approaches. It looks pretty sharp, though it doesn't serve much purpose right now. Hmmm... maybe I can do a "Blair Witch" style "shakey-cam" effect... :)

It's far from perfect - and definitely not ready for prime-time. But it's good enough for now so I can move on and improve on the functionality when dealing with interactive objects. I would also like to incorporate the existing Torque-camera functionality to allow it to follow splined paths. But right now I don't need it.

I'm just excited to be able to move on to something else now.
- posted by The Rampant Coyote @ 12:44 AM (Permalink) 0 comments links to this post

 
Battlefield 2
I went ahead and picked up a copy of Battlefield 2 today. This is a very dangerous game to my productivity.

I was a latecomer to the Battlefield games. I actually missed BF:1942 entirely - I was getting my combat fix (single-player and multiplayer) from Operation: Flashpoint when Battlefield 1942 enjoyed its greatest popularity. Then when I was about ready to give up and try out the game, I heard that BF:Vietnam was about to be released. So I held on a little while longer. I didn't think Battlefield Vietnam was all THAT great, though it did have perhaps the greatest game soundtrack EVAR.

So I got the "true" sequel to the series today (over a week after everyone ELSE I know bought it - yes, peer pressure has been getting to me). I have to say - the improvements in GAMEPLAY over BF:Vietnam are pretty extreme. It just seems like a much more polished and playable product (say that three times fast). It looks like a winner.

Labels: Mainstream Games

- posted by The Rampant Coyote @ 2:23 AM (Permalink) 0 comments links to this post

 
Go Indie... MOVIES!
I just watched Saints and Soldiers, finally. I was really impressed - to the point where it may be one of my favorite war movies of all time (right up there with Glory, Das Boot, and Saving Private Ryan). I knew it was an indie film, but I figured it had to have a bigger-than-normal indie budget. But even for a budget of 5 to 10 million, they really stretched their dollar to bring something with lots of humanity - yet also a fair amount of action (especially at the end).

Then we watched the featurette on the "making of" Saints and Soldier. They mentioned that their budget was "UNDER A MILLION DOLLARS." I was floored. I still am floored. My new heroes are the re-enactors who volunteered their time, talents, equipment, costumes, and expertise to the movie. I know it's a common practice in movies to draw upon these groups, but WOW. I had no idea. Maybe if I'd watched the movie a few more times, I'd notice that you had the same four or five vehicles in all the scenes. Like how Star Wars: A New Hope only had two large ships in the hangar bay that they kept moving around to give an illusion of lots of fighters.

I guess it just goes to show what can be done with a lot of passion and creativity. And about how movies don't need to be about the greatest special effects and name actors.

Labels: Indie Evangelism

- posted by The Rampant Coyote @ 10:15 PM (Permalink) 0 comments links to this post