New Animation System in Place

Initial tests indicate that I may have finally gotten the new animation system working properly...did I mention I'm not very good with math. Anyhow, as an added bonus it appears, believe it or not, that the collision system may be working as well. (I never saw that coming, but I'm not complaining.). But those are VERY initial tests in both cases.

So here's a brief history of the animation system throughout Deep Blue's development.

I. Square Sprites - The initial system was gleaned from the platformer demo in the Visual Studio Express Dev Library. It was the most specific, and limiting of all. It ONLY accounted for square sprite frames (with a 1:1 ratio) layed out in a horizontal line. While this may have worked perfectly and been very efficient for the platformer, you can imagine the limitations it put on sprite design.

II. Variable Ratio Sprites - So, the first thing I did was overload the method with an alternate version that accepted a frame width. I kept the sprites aligned in a horizontal row so that the frame height could be simply pulled from the sprite texture height.

That worked pretty well, except on the larger sprite animations which resulted in extremely long sprites (250 pixel wide frame * 30 frames = 7500 pixel wide sprite). And that just wasn't going to work. Even though it wasn't recommended, things animated pretty well....until the engine started checking for pixel collisions on a sprite of that size. It pretty much brought the game to 2 to 3 frames per second. So after posting and talking with the helpful crew on the XNA forums they suggested a basic rule that no sprite should be larger than 2048 in any dimension, and really, you should shoot for a 1024 max in most cases.

In order for that to happen...other than reducing all my larger animations to 3 frames....I had to lay out the frames in a square spritesheet.

III. Square Sprite Sheets - So my current solution is to lay out the frames in a 1:1 ratio sprite sheet with a max size of 2048 x 2048 pixels using a 1024 x 1024 texture when possible. After loooooooooots of broken math it appears to be working. So now I can have much more efficient sprite sheets and much better frame rates when lots of things are moving on the screen at once.

Each of the above variations was carried out by overloading the same Animation constructor so if I HAPPEN to have an animation that has 1:1 frames that is not over 2048 pixels in texture size I can create it easier than I can the custom square sprite sheet constructor.

All-in-all I'm pretty pleased with the results. It took a little longer than I'd hoped to figure it out, and I went through a bottle of Tylenol in the process but I'm glad to have it out of the way.

Multiple Updates

Although I have to admit, Star Trek Online has kept a little distracted from Deep Blue, it hasn't been all photons and phasers.

HLSL Pixel Shaders
Thanks to an XNA video session by Shawn Hargreaves I've started playing around with some simple pixel shaders in Deep Blue. Earlier I used a pixel shader to add a subtle underwater "glow" effect to the game. It looks a little like you've been swimming in a pool that's been a tad over chlorinated, but I like it.

I used a glow shader from the XNA library on the site so getting it in the game was the big accomplishment, however at the time it didn't mean that I had a good understanding...or any understanding of the HLSL programming.

Now, thanks in part to Shawn's tutorial, I've successfully implimented a slight water distortion effect to the game. One unexpected side effect has been the loss of my nice smooth 'fade from black' fade-ins and I'm still trying to track that one down.

The last shader I really want to work in would be a circular ripple distortion effect for ship explosions and the bubble burst weapon.

Weapons System Update
The new weapons system is about 90% in place. There's a couple of final things to work out but it's a much more flexible system than the way I originally approached it. There are now three types of ammo and three types of firing patterns. Each ammotype has it's own O2 cost, trajectory and damage with easy to modify numbers for game balancing.

Pixel Perfect Collisions
AH! And in another "big win" moment, initial tests are positive that I finally got the per pixel collision detection working, both on animated and non-animated sprites. Further testing is needed, but things are looking pretty promising right now.

I probably need to make an updated game video soon to show off all this progress. Possibly after I get in the treasure system.

Inspired By vs. Educational

Last night I did a bit more research on creatures of the deep (thank you interweb, wikipedia and especially the magic of youTube). The good news is there is a LOT of REALLY cool stuff in the deep ocean...I mean the "Blow your mind, you've got to be making this up kinda stuff". For instance, did you know that at 3,000 feet deep, even though it is too deep for sunlight to reach, it is not a pitch black void. It's more a twinkling lightshow similar to the densest lightening bug swarm you've ever seen. Also, the tiny hatchet fish has photocells on it's underside that has the ability to change color to perfectly match the color of the light above him rendering him invisible from below. It's a built in cloaking device.

The bad news is, at the depths I was planning for the game anything not flashing would be pitch black. Which wouldn't make for a very fun game. I really wanted to game to be covertly educational, showing the diverse wildlife of the deep and some of the cool features about those creatures, but it's hard to be educational and blow the creatures away at the same time. Something seems to get lost there.

Result: I'm going to have to take some pretty big creative liberties with the environment and the enemies, and find some way to work in the factoid elements (possibly on each loading screen).

I think I'm also going to assign Katie to factoid research and copyrighting, cause some of these things are too cool and something she needs to discover for herself.

Happy 2010!

So here we are at the beginning of a new year. Development is still moving along, slowly but moving none-the-less. And I continue to feel more familiar with C# and XNA as things progress. Recently in the XBox indie game library a company called Arkedo Studio has been releasing very well produced, high polish, yet relatively simple games. And I mean "simple" in the best way. The games are incredibly easy to pick up and play. Each has it's own cleverness and/or cuteness. And each has it's own look and feel, yet they all manage to maintain a 'family' style about them.

They are, in my opinion, some of the best, most professional games in the indie marketplace. They also are very limited in what they offer. There is no multiplayer, no save, no achievements or awards, and I have yet to see any kind of customization or personalization in the games. They are, in a way, a nod back to the 25 cent arcade days. Drop in a quarter, play till you die then start the thing all over again.

Of course, the down side to that approach (at least for the player) is they get very familiar with the beginning levels which they can grow tired of early. The up side is almost purely on the development side. It's a lot easier to develop a game when you don't have to worry about multiplayer, signing in, save points, etc.

Yet there are games, current games, that live almost entirely in the replayable world. The first that comes to mind is "Left 4 Dead". Sure, there's an initial exploration and discovery phase to the game the first couple of times through, but after that thanks to the dynamic in-game "director" the game retains a very high replay experience.

So, is there a way to combine the developmental efficiency of Arkedo Studio's "simple" approach with the dynamic replay value of Left 4 Dead? It might be a variation in weapons, ammo, level layout, depth (water), or a variety of other levers and switches

Musical Score

At the moment, trying to throw together a quick musical score for the game. For now it will serve more as a placeholder and reference for tempo and feel more than anything else. The full score to come later.

I am trying something a little different even with the short timeline. I'm experimenting with going half loops and half original music to see if I can combine the two and see if that won't give a less mechanical...loopy feel to the score.

A Few Days Focus on Deep Blue

I'm taking a few days off my normal job. The main reason is it's our 15 year anniversary, but as an added bonus it also gives me a little time to focus on "Deep Blue". The XNA contest is wrapping up this Thursday (ironically the very same day as our anniversary) and I'd like to submit it to the contest...not so much that I think it has any chance of placing, but more because I'd like the 4 month subscription for entering. :)

Besides, if it wasn't for the contest in the first place I never would have gotten this far in the development. So I've spent today working on pickups and screen flow and taking out a few things (such as co-op) for the contest entry.

"Deep Blue" won't be..."done" by Thursday, but at least I'd like to have it in a stable and playable state.

Things taken out that I would still love to include in the final version.
- Signing in the the players to XBox Live.
- An achievement/ranking system, with a save state.
- a "Level" system with multiple levels including bad guys and environments
- and local co-op (saving XBox Live co-op for another project)
- oh...and a better timing system for entering and exiting a game.

So with all that it still may be a little while until "Deep Blue" is ready to hit the marketplace but if I can get all those in then I feel it will be a very "complete" game.

Enemy Mine...

...no, not the Dennis Quaid movie, these are simply proximity/radius enemies in Deep Blue. Whether or not they have movement yet is still to be tested.

Enemy Ship 2

Fresh on the heels of the armored enemy ZBrush design is this second enemy ship. This ship, which is still unnamed, is much smaller and faster than the bulky armored ship. It's oversized claws are inspired by the real-world "Pistol Crab" which can essentially create a sonic burst with it's claws so powerful it actually creates LIGHT and stuns it's prey (soon to be dinner) from a distance. Seriously, I'm not making this up, search for it online.

Anyhow, just like the Pistol Crab, the claws here are an excuse to have a ranged weapon. Yes, the first of our bad guys that actually fires back at you.

Video Update

Long overdue, but finally I've put together a tiny video update. Some things are still obviously placeholder, such as the UI and the enemies, but things are starting to fall together.

As all the basic pieces come together and playtesting the full experience really gets moving, a real game is beginning to emerge.

When I began, I started trying to select the simplest of game mechanics, trying not to bite off too much. I started off with a single player, controlled by a thumbstick, had him fire a single weapon and blast as many bad guys as he could. Calculate a score and we've got a basic game. Mission Complete!

However, as I began to feel a little more comfortable with C# and XNA other ideas began to pop up, ideas that didn't seem to hide behind mounds of terrifying C# code, so I figured I'd give them a shot. Throw in an oxygen resource and cost/benefit mechanic...done. How about a secondary bubble burst weapon....done. What about a depth mechanic that ties to the oxygen usage...done.

Step back and things begin to really shape up. Then more ideas hit that seem to make sense, other enemy/hazard types. More weapon variations. Upgradable ship node with an associated economy system.

IF I can actually manage to get all that in "Deep Blue". IF I manage to write to code to make it all behave properly. And IF makes the game more fun...then this little experiment of a project may become something a little bit more.

And then there was sound

I've got a pretty decent amount of experience with audio creation in my past. So I have to admit, it is a little bit of a relief to step away from the "bold/new" of C# and get back on more familiar ground of music and sound effects.

Even being more familiar to me, I was a little concerned about getting audio into XNA with all the posts and questions/troubles that I've seen people had about audio on the forums. Luckly...so far, knock on wood, things are going remarkably smoothly. Honestly, I really like the authoring tool.

I've created a few simple sounds for the gameplay and the UI, create a few variations on certain sound effects and tweek volume and pitch levels so it all blends together correctly. The two remaining big steps I have to take with the audio are longer audio files, such as background music, and testing out the files on the 360. But so far, everything has worked out painlessly on the PC.

Kodu Fun

For those of you aspiring game designers out there (especially the ones without a masters degree in programming), I highly recommend checking out the "Kodu Game Lab" available for the xBox 360 on the Live Marketplace.

It released last week and is a great way for starting game creators to get their ideas going. All authoring is done on the 360 through a series of circular menus and iconic programming. The programming feels very "LEGO". It's very easy and quick to get a game up and running.

There are of course limitations. You're not going to be creating Halo any time soon on Kodu, but for simple games it's a lot of fun. There are currently around 200 3d assets to choose from (I've heard...but personally I find that number a little high) and the dev crew did a good job of creating assets for a wide range of games (sports, racing, shooter, platformer...etc.). It's a little like going to Toys R Us and grabbing a lot of generic playing pieces out of the board game isle and throwing them all in a box

There is a free trial, but the program itself is $5.00, but well worth it for the time you'll spend playing around.

Hopefully in the future they'll release 'asset packs' which will enable you to have even more items to play with.