Lapse

Hello, faithful few.

While I realize I was never terribly prolific here to begin with, I thought I'd pop in nevertheless and note that I'm especially unprolific (it's a word because I SAY SO!) lately because I'm in the process of buying a house.  I close in just over a week, and then it'll be moving and buying furniture and whatnot, so development on Let's Get Tanked will continue to stagnate for the time being.

Over and out!

Shameless Plug: SpiderOak.com

I back up my game programming files to the cloud using SpiderOak. Sign up and get 2GB of storage for free, or pay some money and get more storage to fit your needs. Use this link and get an extra free GB for yourself and for me! Your files are encrypted on your computer before being transmitted to SpiderOak (and decrypted after download), so your data is always secure.  Plus, it's Linux-friendly!

https://spideroak.com/download/referral/1f682bf028234e36c41a04fe71116b15

Disclaimer: If you use the above link to sign up for SpiderOak, I get compensated in the form of an additional free gigabyte of storage for my account.

Vidyuh!

Behold my tanky awesomeness.

Sorry for the terrible quality imposed by Blogger video, but you get the idea.  It's really cool on a 42-inch HD TV!

Holiday!

Happy Thanksgiving, dear readers*!

I'm hoping to get some good work done over the holiday weekend.  I'll be spending a lot of time at my parents', availing myself of their easy chair.  I find a good recliner is the most comfortable place for laptop-based development.

* - I know you're out there.  I can hear you breathing!

On Videos, and Them Not Existing

So I got some friends to play Let's Get Tanked! in its current state so I could capture a video.  Except I pressed the wrong button, and no video was captured.  Sadly I didn't realize it until much later.  There WILL BE VIDEO!  Just not as soon as I'd hoped.

Pow! Biff! Bop! Whammo!

That's right, folks.  Sound effects.  I haz them.

Actually, Let's Get Tanked (I now reveal the name of my current project!) has them, and collision detection between bullets and tanks.  Video coming as soon as I can hornswaggle three friends to play local multiplayer with me long enough to capture a quick film.

It's really starting to come together.  I am becoming cautiously optimistic.

Okay, okay, I'm golly-well excited!  It's starting to feel like a real game now that four people can drive their tanks around and shoot at each other, and hear a big "kaboom" when they get a hit.  Woo!

Well That's Dumb

I resolved my rendering issue thanks to this XNA forum post which indicates that Viewports (which determine which portion of the screen actually gets drawn on) initialize with maximum and minimum depth set to zero.  This explains why the problem on xbox only showed up when I was using split-screen, as it involves creating new viewports.  So basically all the depth calculations were getting clamped between 0 and 0, effectively rendering the depth buffer useless.  A quick change to explicitly set appropriate minimum and maximum depths (0 and 1) fixed the problem completely.

What I don't understand now is why the problem DIDN'T show up on Windows, but I really don't care at this point.  There are other weird problems happening on Windows that don't happen on xbox (for some reason, my game sounds don't work on Windows, but they work on Xbox), and I can't be bothered to track down the cause.  Probably I need to do a fresh reinstallation on my laptop, but again, can't be bothered.

Anyway, the important thing is it's working correctly now!  I can carry on with fruitful development instead of banging my head against bugs.

Render WTF

This past weekend I successfully got a four-player local split-screen demo running on the xbox, and encountered a severe render bug that I have yet to quash, because it only occurs on xbox.

For some reason that I haven't even begun to uncover, my models on xbox render as though the depth buffer is turned off.  I've checked the code and the depth buffer is definitely turned on; in fact, the same code renders the same model at a different point in the game with no errors whatsoever.  This one's gonna be tough to track down.

Anyway, it does work correctly on my development machine, and I'll post a video soon.  It looks pretty awesome if I have to say so myself. ;-)

Billboards, an Update

Last night I finally had a breakthrough moment with the billboard thing I discussed in my previous post.  It took some time to get it right, because my bullets (which are modeled after a popular open-source game's design) have alpha gradients.  The trouble with alpha in general is that it doesn't look right if objects are drawn out of depth order. 

To illustrate, imagine two objects, A and B. A is nearer the viewer and a semi-transparent color.  B is farther from the viewer, partially obscured by A (i.e. visually overlapping), and nearly opaque.

If B is drawn first followed by A, you'll get what you expect: a view of A, with the obscured part of B semi-visible through A.  However, if A is drawn first, the portion of B overlapped by A will appear in front of A, even though foreshortening and other depth cues would indicate it is behind.

This would be easier to explain with a diagram, but I'm not somewhere I can easily draw one.  Google around for alpha blend depth sort if you want to learn more.

Anyway, the well-known solution to this is to always draw alpha-blended objects in reverse depth order; that is, draw objects that are farther away from the viewer before drawing objects that are nearer.  This of course requires additional processing to sort the objects prior to passing them to the render pipeline.

After doing a lot of searching and seeking of examples, I finally landed on the solution of creating an unsorted vertex buffer and a sorted index buffer.  This helps to minimize computational overhead in the sorting process, as it needs only to move 4-byte integers around instead of entire vertex declarations (which, in this example, are 64 bytes in size).  Of course, sorting does require knowing the distance from the viewer, which means doing extra work in the form of applying the view and perspective transformations to every vertex to discover their depth.  Fortunately that happens pretty quickly, even in software.

I also decided to reduce the likelihood of garbage collection trouble and made the vertex buffer a static array, and use it in a ring queue form.  The index buffers are destroyed and recreated every frame, but the vertex array stays put in memory for the lifetime of the containing object.  Since the index buffers are usually fairly short (six indices per shot, times however many shots are active on the screen at once which usually isn't many and can be limited by game rules), garbage collection isn't too much of a concern.  Again, it's 6 x 4 (six 4-byte indices), or 24 bytes per shot, instead of 4 x 64 (four 64-byte vertices), or 256 bytes per shot.

SO, after a wild evening of coding, I now have a working blaster.  I may post a video; I'm rather proud of my accomplishment!

Billboards

No, not the things you see on the highway.  A billboard is a special kind of flat surface in a 3D environment that is always oriented toward the observer.  Billboarding is a technique often used to put objects into a scene that would be too costly to model out of polygons, by texturing the billboard with an image of the object.  Frequently this technique is used for foliage; the illusion is good enough as long as the observer isn't right up on top of the actual billboard polygon. 

So, I've been learning to use billboards, after making a remarkable discovery about an open-source game (which is providing much of the inspiration for my main current project).  That game involves lots of round projectiles flying about, and instead of modeling the projectiles, they're rendered using billboards.  Consider: A sphere that will look reasonably smooth is made up of hundreds of individual triangles, whereas a billboard is (typically) made up of just two.  That's a savings of hundreds-less-two per projectile!  Brilliant!

Anyhow, that's what I've been up to most recently.  That and a bit of music composition.  I've decided that this game, which is a shooting game, will be complemented best by a downtempo soundtrack.  A little comedic dichotomy of violent gameplay married with soothing music.

Lone Wolf

Woof.

This lone wolf game company thing is a lot of work! And more often than not, I don't want to actually do the work, ya know? 

Mostly the setbacks are artistic ones.  Anyone want to make models or textures for me? 

This weekend I am going to try to buckle down and make some progress.  Recently I did complete the main menu system for the current focus of my efforts (I've mentioned before that I've got four different projects in progress, right?).  The one I'm working on right now is a multiplayer tank combat game.  The other three are a unique approach to brick-breaker games, a maze navigation game, and a racing game.

So, hopefully that means I'll have something worthwhile to report next week.  Some actual progress, hey?  That'll be novel.

What Were They Thinking?

I am stepping slightly out of character and significantly off-topic because I am watching Stargate Atlantis on Netflix.

Why is Tayla singing?!?!?!

In other news, I'm working on menus for the next game I think is most likely to hit the market.

Simplify, Simplify, Simplify

I've realized that my biggest obstacle to releasing a game is my tendency to over-complicate it.  Not necessarily in the sense of complicated game-play, but in the sense of thinking of feature after feature to add.  That of course means more time spent developing and debugging.

The reality is that this is a game I'm going to sell for a dollar.  One measly dollar!  So, I've reached a conclusion. Simplify!  Simpler features, simpler graphics, simpler everything.

This'll be hard to stick to!  We'll see how it goes.

The Sound of Silence

I've not posted anything in a while.  That's because I haven't done much XNA coding lately.  Work and other demands on my time have left me with little energy for it!  I'm at the second of two trade shows for my employer at the moment; once I'm home from this, my summer should mellow out and I'll have more time for Xbox development.

Animating Avatars

I've started on a side project to create a tool to make it easy to create animations for avatars (whew, what a string of infinitives!).  Once I'm done with it, I may release it as an open-source tool for the community, assuming the community doesn't already have something better!

After that, I'll be tackling XACT.

Monetization

I don't think (m)any people read this blog yet, but I've gone ahead and added AdSense advertising to the layout.

So.  Despite your best intentions, please do not click the ads unless you're genuinely interested in the advertised product.  If AdSense has any reason to suspect click fraud, I could have my account suspended.

Thanks!

Apparently, 12,000 Vertices is a Lot

I discovered that the slowdown had nothing to do with my camera class, and possibly everything to do with something called predicated tiling.  In short, the Xbox has but 10 MB of high-speed video RAM (a major WTF factor for many developers, although clearly a well-designed game can make do).  When rendering in 1080p resolution, that means there's a good bit of memory shuffle going on in order to get everything drawn.  When "everything" is 12,000+ vertices, that means a LOT of shuffle, and draw cycles don't complete on time.

So, for now, I've dropped back to rendering at 720p.  I don't like the loss of resolution, but it eliminates the problem.  Later I will start to investigate mechanisms for only drawing subgroups of vertices that have a high probability of being visible.

For now, I think I am going to focus on gameplay.  I have three or four main modes of play in mind, each of which shouldn't present an insurmountable challenge, and together should make for a game with plenty of replay value and should sell pretty well.

Falloff and Avatars

Yesterday's coding resulted in:

• Finishing the geometry for all useful maze cells (I decided to skip the completely enclosed cell, as you can't get inside it anyway...)
• Tweaking the normal map for a texture to make it look more totally awesome
• Adjusting the shader to implement light falloff (things that are farther away appear dimmer according to the Inverse-Square Law)
• Making the maze walls "work" (not allowing the player to move through the walls)
• Putting a You-Are-Here blip on a 2D map view
• Putting the first NPC avatar into the maze

I also decided to have a little fun, and make the NPC avatar dance when the player enters the same cell.  A sort of "yay, you found me!" dance.

While I was at it, I also discovered that the class I've created to implement a camera with Yaw/Pitch/Roll controls has a bug that I cannot seem to chase down.  Adjusting the Yaw parameter sometimes leads to a slowdown in the game.  Actually, I'm not sure the camera class is to blame yet, but it seems a prime suspect.

I also had some fun with rendering.  I added some code to generate an anaglyph stereo image.  Of course it means the colors get distorted, but the effect is pretty exciting.  Unfortunately, the method I've chosen for actually rendering an anaglyph is very time-consuming (because it involves resolving two render targets, which are expensive operations) and blows the framerate to heck. Ah well, the price of coolness.  I'll figure out a way to optimize it if I decide to put it in the finished version.

Anyway, all of this adds up to one very excited Brian!  Nothing like learning new things and making stuff work to really fuel the fire of determination.

Progress and Learning!

Today I learned how to use tangent and binormal vectors plus a custom shader to implement normal maps.

I also began work on basic rendering of my maze data in three dimensions.  It's a bit tedious; I've taken the path of generating vertex data dynamically and that means a lot of lines of creating new vertices.  Basically, imagine that a maze is made up of four-walled cells (as visible in the video a few posts back).  If each of four walls can either be open or walled, there are sixteen total possible combinations.  That means sixteen different sets of 32 dynamically-generated vertices (give or take), for a total of 512 hard-coded vertex coordinates.

Now of course, there's a lot of duplication.  I can, for example, generate vertices for a cell with one wall, then rotate it to generate the other three one-wall cells.  Same applies for a cell with two and three neighboring walls. Then there's two parallel walls, which only has two unique forms.  So that cuts down on some of the trouble.  Nevertheless, it remains tedious.  I'll be glad when that part is done.

At any rate, I certainly came away from today's coding with a sense of accomplishment -- normal maps work, and the 3D cells I have completed look awesome on screen.  Maybe some pictures when I get all the cells defined.

Texture Wrapping Trouble

We all have stupid days sometimes.  Tonight I can't figure out why a texture isn't tiling properly.  I've got a thread over at the XNA forums.  Check it out here.  Chime in if you know anything!

Update: Resolved within hours, thanks to the great folks at the XNA forums.  Now my texture is tiling, and the world is once again saved.

Gee Thanks, Blogger...

Dear Blogger,

Please regurgitate the post you gobbled up from my blog.

Sincerely,
Brian.

But seriously folks, I had a post called "Amazing!" that has vanished and I have no idea why.  It's just gone!  It was a nice long post and even had a video, too...

EDIT: See, somewhere Blogger still even thinks it exists:

...How frustrating!

Another update:  It seems this is a known issue.  Here's hoping my entry is restored.

Another update:  Looks like it's back.  Thanks, Google!

Amazing!

I've started a new, hopefully quick-to-market project since I've watched most of my other main ideas grow into incredibly involved behemoths (that's not a bad thing; just means I need something else quick to make some money in the short term).  So I've come up with a new idea.  I won't go into any specifics yet (industry secrets and all!), but I will mention that it involves randomly-generated rectangular mazes.

So tonight I started the project and, in the course of about four hours, have implemented a maze generator that uses the Recursive division method.  Since this is all very early proof-of-concept code at this point, I added some extra fluff to the generator which allows single-stepping through the generation process (which is reflected by a very simple sprite-based depiction of the maze data).  It may be a very simple algorithm, and it may be a very simple proof of concept, but by golly it's cool to see it work!  In fact, let me not simply say it's cool.  See for yourself!

Cool, right?  Right?...okay, so maybe I'm easily entertained.  Nevertheless...  I now have a simple mechanism to generate maze data for me to use in the game.  Now I can move to actually using the maze data for its intended purpose!  (The potential collaborator I mentioned in the previous post?  I've asked him to implement a different generation algorithm known as the Randomized Prim's algorithm.  Different algorithms result in mazes with different "character".  I'll probably wind up using a variety of algorithms in the finished product.)

The Team Grows?

Tonight at a meeting of my Dungeons & Dragons group, I mentioned that I am an xbox indie games developer.  One of my friends piped up and asked if I needed another developer.  So I've just sent him a wordy e-mail describing what to expect out of doing work for [undecided] games (as in, don't expect to make any money unless a project sells), and an initial, nicely self-contained first assignment implementing a particular algorithm.  That'll be cool, having a collaborator with whom I can discuss coding issues.  Anyway, we'll see where it leads!  He's getting married in just a few weeks, I think, so it'll probably be a while before he's able to actually do anything productive for me, but that's fine.  I'm no worse off than I already was!

This Is Why I Don't Blog...

I never have enough to say.

I did end up getting the Wacom tablet.  I got one of the larger Bamboo models.  It's neat, but I'm afraid it's going to be little more than an expensive toy for me rather than a frequently-used tool, as I'm quickly finding my hand-eye coordination lacking.  In other words, I can't draw for beans.

In other news, I've been playing Fable III a lot.  Pretty decent game, except that it continues in the Fable tradition of having an almost worthless map system.  In fact, Fable III's map system is arguably worse than that of Fable II.  In Fable II, it was essentially impossible to easily view the relations between major map areas, but a given area was mapped fairly accurately, and provided markers for your current location, etc.  By contrast, in Fable III, the layout of the maps doesn't reflect "reality" at all.  Well, that's a bit severe; a few features here and there vaguely resemble the actual layout of the area.  That said, it's not very useful for general navigation.  Perhaps the makers feel that is an important aspect of the game.  I could do without it.

Wacom Tablet

I'm thinking about getting a Wacom graphics tablet.  I'm not a visual artist at all, but now that I am engaged in long-distance collaboration, the ability to sketch directly into digital form would be indispensable.  Especially since I don't have a scanner with which I could quickly digitize sketches on paper.  Good-sized ones are a few hundred bucks...but I'm about to get a nice fat tax refund from the IRS, so maybe I can spend some of that on a tablet.  We'll see.

Please Bang Head [Here]

XNA 4.0 presents Vertex and Pixel Shaders 3.0, which support Hardware Instancing.

Hardware Instancing works like this: Say you have an object (e.g. a projectile of some sort) that you want to draw a whole bunch of times (a barrage of said projectiles).  It's really CPU intensive to make a bunch of draw() calls with separate transformation matrices.  Instead, one can load all the transformations into a separate vertex buffer and let the GPU sort it out with a single call to draw() (which it will -- it will automatically duplicate the mesh vertices for each transformation matrix).

Sounds great, right?  Definitely.  Instancing is a critical technique for exactly the kind of situation I described (a lot of projectiles flying about).  Unfortunately, there's a catch.  A slight difference in behavior between running on Windows and on Xbox.  Let me esplain.  No--there is too much.  Let me sum up:

A Model (the logical representation of one complete object) can be made up of multiple Meshes (the logical representation of all vertices that make a single solid part of said object).  In Windows, instancing an entire Model works perfectly.  On Xbox, however, what makes it to the screen is one complete model (the first instance), and then a bunch of copies of the first mesh for the rest of the instances.  Say your Model is a rocket, made up of Meshes for the body and individual tail fins.  Say that a tail fin happens to be the first Mesh in the Model.  Now imagine that you're trying to draw a bunch of rockets flying around, but what you get is one whole rocket and a bunch of disembodied tail fins flying around.

One workaround is to combine all the vertices in the entire Model into a single Mesh.  This is bad for a number of reasons.  First of all, for me, it means hand-editing the .fbx file that stores the Model data.  It's possible; the file is human-readable, but it's a really awful task.  The second reason it's bad is that it screws up texture mapping.  Each vertex in a Mesh has a set of texture coordinates, that can refer to exactly one set of textures for the entire mesh.  This is exactly why Models often have more than one Mesh, so that different sets of textures can be used for each part of the Model.  So for a single-Mesh Model, you'd have to squeeze all your textures into a single image and re-map the entire model.  Possible, but hugely impractical for my operation.

Anyway, this leads to much head-to-wall banging for me as I try to work around the problem.  I've posted a thread in the XNA community forum for assistance; hopefully one of the really smart folks will jump in and help me out.

Making Friends

I've just made contact with a potential collaborator; someone who can do decent low-poly-count models.  This is exciting.  Not being able to decently model anything much more complicated than a box (and being almost a total write-off in the texturing area) is something of a setback for me.

So, hopefully I'll be able to form a working relationship with this individual, if she is willing to work for promises (I can only pay if/when the game sells...).

For that matter, if anyone's out there reading this who's also got any artistic talent, particularly in 3D modeling or music, and willing to work for the love of it, drop me a line!

Why [undecided] games?

It's really a quite simple story.  Xbox Live Indie Games requires that you provide a company name when you register your account.  I hadn't come up with a good one yet, so I filled in "undecided".  It's next to impossible to change your company name after you've provided it, and I sort of like it anyway.  's got a bit of a ring to it.  So there you have it; the story behind the name.

Version Upgrades and Setbacks and Hacks, Oh My!

Settle in, folks; I get a bit long-winded in this one.

First, some background for the completely uninitiated:
Microsoft has, for the Xbox console (and now Windows Phone 7), a do-it-yourself development model that bears quite a bit of resemblance to the Apple iTunes App Store -- Anybody that has the skills and is willing to pay for a membership (and has the necessary equipment) can design a game for Xbox, submit it for peer review, and ultimately sell it in the Indie Games section of the Xbox Live Marketplace.  The software tools required for Xbox development are Visual C# Express and XNA Game Studio.

Then, a little personal history:
I've been an Indie Games developer for around two years now.  When I started, Visual C# Express 2008 and XNA Game Studio 3.0 were the current versions to have.  I developed and marketed Distraction using XNA 3.0.  XNA Game Studio 3.1 came out a little while after I got involved, and I upgraded with little hassle.

Now, on to the real point of today's post:
Today, I thought I'd do my part as an Xbox Indie Games community member and review some games.  The first one I downloaded to review required the fairly new XNA 4.0 release.  So, I figure, hey -- I've put it off long enough.  Let's take the plunge and update to Visual C# Express 2010 and XNA Game Studio 4.0.

So I install the software and update my current project ("Arka Nightmare in 3D" -- playtests coming in a few months for registered Xbox Live Indie Games developers).  Go to build it and WOAAAAAAHHH!  Errors out the wazoo!

It seems that Microsoft has made some significant changes to portions of the XNA API.  Breaking changes (meaning changes that make older software break).  And now we get to the real headache inducing part: The addition of the concept of Graphics Device Profiles.

XNA 4.0 has two profiles to choose from; "Reach," which targets the widest platform base (and supports the weakest hardware), and "HiDef," which targets higher-end hardware to the exclusion of older PCs and Windows Phone.

Sounds great, right?  Right.  Except that my laptop's graphics chipset isn't supported by HiDef.  And therein lies the rub for Arka Nightmare: Its graphics code requires features that only exist in the HiDef profile.  If I cull my code to run under the Reach profile, performance is awful. If I build for HiDef, I get an error when I try to run it on my laptop.

The really frustrating aspect is that my laptop (a ThinkPad T60p) is actually capable of performing most of the tasks that HiDef would demand of it, and is fully capable of the tasks that Arka Nightmare needs it to do (hardware instancing using Vertex Shader 3.0).  What is a cash-strapped developer to do??

Fortunately, I'm far from the only one to run into this issue, and it's already been hacked around by some very smart people.  It turns out that by using some of the nittier, grittier features of the C# language (that I never use in my code and therefore don't really fully understand yet), you can actually disable the profile checking that XNA does, so that it doesn't notice that the graphics hardware isn't quite fully capable of all possible HiDef demands.  Here's a link to the code that pulls off this money-saving miracle, done by a UK developer calling himself FatBat Games.

So Arka Nightmare is mostly back to its pre-XNA-4.0 glory, minus a few rendering glitches due to parts of the new API that I haven't figured out yet (and may well become the subject of future posts!).

Most likely next up: The dropping of support for point sprites in XNA 4.0 (which prevents me from bringing Distraction to 4.0 yet, as it uses point sprites heavily).

Well Hello There...

Welcome to the blog home of [undecided] games.  Please don't steal my name.

I am a fly-by-night solo Xbox Live Indie Games developer.  I figured I'd start a blog and see if that could improve exposure and thereby make more money for me!

Things I'll post here will mostly be tidbits about progress I'm making on my latest projects.  I do, however, reserve the right to post whatever I feel like posting!  Gosh!

Anyway, thanks for visiting.  Be sure to check out my published games on Xbox Live Indie Games, which will be linked in the box to the right.