by date
Collaberation, technology, creative vision, and download sizes...
Collaberation, technology, creative vision, and download sizes...
| Name: | Jon Frisby |  |
|---|---|---|
| Date Posted: | Mar 31, 2006 | |
| Rating: |  4.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Jon Frisby |
Blog post
So today I received the final deliverable from Exis Inc for a very tiny project I contracted their services for. Specifically, my designer came up with the idea of having a "fractal"-themed skin in my game and came up with a very lovely looking prototype:
The problem: How do you make that animated? For other skins we could break out graphical elements as separate sprites and either do drawn animations, or programatically animate them. For this skin, you'd need to do real 3D rendering -- there's just nothing to "break out". Now 3D animation is not an area of expertise for my designer so having her do it would mean having her take a month off from work, hide in a cave, and slave away at it. Not good for her, not good for her employer, and so forth. Then I met Peter on IRC, and before I knew it we were negotiating a contract and he was on his way. I tasked Peter with coming up with something along the general lines of what my designer (oh for god's sake! Let's just give her a name -- let's call her Jane, that's much less tedious than typing "my designer" over and over and over...) had proposed. I left it general because emulating *that specific* mockup would likely be tedious (and thus expensive), and potentially limiting.
After a couple weeks of work, and some back and forth with my "Jane" and I nitpicking over minor details Peter delivered a wonderful, but low quality sample that my designer and I were content with and I sent him a check. The deliverables consisted of some text elements for things like score and such (delivered as .png files), and an uncompressed video clip at 640x480 resolution. After downloading a 142MB .zip file that uncompressed to reveal a 350MB .avi I finally got to see Peter's work at full resolution and sans compression artifacts and I'm completely blown away!
Now I find myself preparing Ogg Theora versions of the video. After fighting ffmpeg2theora (it was producing some bizarre color problems until I figured out that I needed to convert from 32-bit color to 24-bit color before feeding the data to ffmpeg2theora...) for a bit I now have 40 Ogg Theora files sitting on my desktop: 4 different resolutions, 10 quality settings for each.
Unfortunately the 640x480, quality 10 version is 7.3MB. Ouch! For comparison purposes, the high quality H.264 version produced by Quicktime Pro is 312KB. Granted, the quality isn't as good but 312KB is much more manageable than 7.3MB...
I have two concerns about file size: 1) The download size of my game. The "full" version (the one you purchase) can probably be relatively large but the trial version has to be relatively small. Somewhere in the ballpark of 20-40MB is what I've seen people mention as the magic limit. 2) I need to smoothly switch from skin to skin, so I need to be able to stream data off the disk quickly and seamlessly. 7.3MB is a HUGE chunk of data to be reading from a disk. My target baseline is a 4500RPM hard drive after all...
Now, mind you that I'm going to have 15-20 skins, and for things like this I'll need to include SEVERAL versions to allow for performance/quality tradeoffs. (I'll probably be shipping 2 versions of every particle effect for example. Three quality settings for particles: Max, Medium, and Min where "Min" turns all but the most essential particle effects off completely, and uses the low quality versions for what it must, "Medium" where all effects are shown in low-quality, and "Max" where all effects are shown in high-quality.)
For this particular video element I'm currently thinking of shipping the "quality 5" versions in 320x240, 512x384, and 640x480 which would total about 3.5MB. That's an awful lot for just one skin, and that's without the other graphical elements (tiles, board, overlays, particle effects) or audio!
Of course, this is all putting the cart before the horse: Out of the box, T2D's resource management capabilities just won't let me do what I need in terms of streaming resources off disk. Actually, "streaming" is a bad choice of words here. Let me explain:
T2D can "stream" audio off the disk as needed, but it takes a few milliseconds to do so and it blocks execution of the game while it does. So for sound effects that fire based on player actions this causes a noticeable and highly annoying pause and for audio it means that the "timeline" is slightly out of sync with the music -- and you'd be surprised at just how easily noticeable that is. Preloading the audio at start-time is unacceptable too: Even with music for just 2 skins the startup time is dramatically increased (more than doubled in fact), and each skin will have its own music. That doesn't even cover the memory usage!
There's also the little issue of video: Ogg Theora playback is limited to a GUI control that doesn't even support looping. Of course pausing/unpausing of audio and video are both impossible out of the box but there's a great resource to add pausing of audio and I've made a resource that allows pausing of video. However the video I don't even have the OPTION of preloading. It gets loaded when you tell it to play a file. Period.
Now my game has one interesting characteristic that can be leveraged: I know FAR in advance what resources I will need next. By "far in advance" I mean at least 30 seconds. If only there were a way to fetch audio/video resources asynchronously, I could just say "I am starting skin A now, so go and fetch the resources for skin B in the background" and then when I switch to skin B, unload the resources for skin A.
I have been programming for a good 15 years now, and I've even met Bjarne Stroustrup but I am NOT a C++ programmer and I know enough about C++ to know that what you don't know CAN hurt you -- this is doubly-true of threaded programming which is hard to get right in ANY language. So implementing what I need myself is simply not practical.
So for the first part: Asynchronous prefetching and unloading of Ogg Vorbis audio data I have contracted the services of Tom Bampton. He moves fast! He's almost done in fact, only a week or so after I first asked for his help! I can't wait to cut him a check (err, PayPal transfer) and release his work as a resource!
For the second part: I need a hypothetical t2dTheoraSprite that has the same asynchronous preloading and unloading capabilities as Tom's audio patch. I imagine this one is gonna cost me a bit more than the audio patch but if I'm lucky enough that Tom can commit the time to the project this one will also make it out as a resource.
Once I have those two technological pieces in place though, I can finally begin to pull together all the pieces and get this game into a state that will knock peoples' socks off. Now I just need to make sure that I don't go overboard and make every skin be 7MB in size... That would be bad.
-JF
The problem: How do you make that animated? For other skins we could break out graphical elements as separate sprites and either do drawn animations, or programatically animate them. For this skin, you'd need to do real 3D rendering -- there's just nothing to "break out". Now 3D animation is not an area of expertise for my designer so having her do it would mean having her take a month off from work, hide in a cave, and slave away at it. Not good for her, not good for her employer, and so forth. Then I met Peter on IRC, and before I knew it we were negotiating a contract and he was on his way. I tasked Peter with coming up with something along the general lines of what my designer (oh for god's sake! Let's just give her a name -- let's call her Jane, that's much less tedious than typing "my designer" over and over and over...) had proposed. I left it general because emulating *that specific* mockup would likely be tedious (and thus expensive), and potentially limiting.
After a couple weeks of work, and some back and forth with my "Jane" and I nitpicking over minor details Peter delivered a wonderful, but low quality sample that my designer and I were content with and I sent him a check. The deliverables consisted of some text elements for things like score and such (delivered as .png files), and an uncompressed video clip at 640x480 resolution. After downloading a 142MB .zip file that uncompressed to reveal a 350MB .avi I finally got to see Peter's work at full resolution and sans compression artifacts and I'm completely blown away!
Now I find myself preparing Ogg Theora versions of the video. After fighting ffmpeg2theora (it was producing some bizarre color problems until I figured out that I needed to convert from 32-bit color to 24-bit color before feeding the data to ffmpeg2theora...) for a bit I now have 40 Ogg Theora files sitting on my desktop: 4 different resolutions, 10 quality settings for each.
Unfortunately the 640x480, quality 10 version is 7.3MB. Ouch! For comparison purposes, the high quality H.264 version produced by Quicktime Pro is 312KB. Granted, the quality isn't as good but 312KB is much more manageable than 7.3MB...
I have two concerns about file size: 1) The download size of my game. The "full" version (the one you purchase) can probably be relatively large but the trial version has to be relatively small. Somewhere in the ballpark of 20-40MB is what I've seen people mention as the magic limit. 2) I need to smoothly switch from skin to skin, so I need to be able to stream data off the disk quickly and seamlessly. 7.3MB is a HUGE chunk of data to be reading from a disk. My target baseline is a 4500RPM hard drive after all...
Now, mind you that I'm going to have 15-20 skins, and for things like this I'll need to include SEVERAL versions to allow for performance/quality tradeoffs. (I'll probably be shipping 2 versions of every particle effect for example. Three quality settings for particles: Max, Medium, and Min where "Min" turns all but the most essential particle effects off completely, and uses the low quality versions for what it must, "Medium" where all effects are shown in low-quality, and "Max" where all effects are shown in high-quality.)
For this particular video element I'm currently thinking of shipping the "quality 5" versions in 320x240, 512x384, and 640x480 which would total about 3.5MB. That's an awful lot for just one skin, and that's without the other graphical elements (tiles, board, overlays, particle effects) or audio!
Of course, this is all putting the cart before the horse: Out of the box, T2D's resource management capabilities just won't let me do what I need in terms of streaming resources off disk. Actually, "streaming" is a bad choice of words here. Let me explain:
T2D can "stream" audio off the disk as needed, but it takes a few milliseconds to do so and it blocks execution of the game while it does. So for sound effects that fire based on player actions this causes a noticeable and highly annoying pause and for audio it means that the "timeline" is slightly out of sync with the music -- and you'd be surprised at just how easily noticeable that is. Preloading the audio at start-time is unacceptable too: Even with music for just 2 skins the startup time is dramatically increased (more than doubled in fact), and each skin will have its own music. That doesn't even cover the memory usage!
There's also the little issue of video: Ogg Theora playback is limited to a GUI control that doesn't even support looping. Of course pausing/unpausing of audio and video are both impossible out of the box but there's a great resource to add pausing of audio and I've made a resource that allows pausing of video. However the video I don't even have the OPTION of preloading. It gets loaded when you tell it to play a file. Period.
Now my game has one interesting characteristic that can be leveraged: I know FAR in advance what resources I will need next. By "far in advance" I mean at least 30 seconds. If only there were a way to fetch audio/video resources asynchronously, I could just say "I am starting skin A now, so go and fetch the resources for skin B in the background" and then when I switch to skin B, unload the resources for skin A.
I have been programming for a good 15 years now, and I've even met Bjarne Stroustrup but I am NOT a C++ programmer and I know enough about C++ to know that what you don't know CAN hurt you -- this is doubly-true of threaded programming which is hard to get right in ANY language. So implementing what I need myself is simply not practical.
So for the first part: Asynchronous prefetching and unloading of Ogg Vorbis audio data I have contracted the services of Tom Bampton. He moves fast! He's almost done in fact, only a week or so after I first asked for his help! I can't wait to cut him a check (err, PayPal transfer) and release his work as a resource!
For the second part: I need a hypothetical t2dTheoraSprite that has the same asynchronous preloading and unloading capabilities as Tom's audio patch. I imagine this one is gonna cost me a bit more than the audio patch but if I'm lucky enough that Tom can commit the time to the project this one will also make it out as a resource.
Once I have those two technological pieces in place though, I can finally begin to pull together all the pieces and get this game into a state that will knock peoples' socks off. Now I just need to make sure that I don't go overboard and make every skin be 7MB in size... That would be bad.
-JF
Recent Blog Posts
| List: | 09/20/08 - 3 days of AGDC, untold weeks to recover... 08/28/08 - DEATH TO YOUR BALLS! 04/13/08 - Hordes of Orcs for Windows, Harmonic Convergence, and Revenge! 02/20/08 - I CAN HAZ GAME BALANCE? 02/11/08 - 240 days, and counting! 12/15/07 - My milkshake brings all the orcs to the yard... 09/20/07 - "Gentlemen, I'm goin' home in my new car." 09/17/07 - OH GOD!!!! THE ORCS ARE INVADING!!!!!! |
|---|
Submit your own resources!| Lee-Orr Orbach (Mar 31, 2006 at 09:35 GMT) |
| Don Hogan (Mar 31, 2006 at 15:08 GMT) Resource Rating: 5 |
| Jeff Tunnell (Mar 31, 2006 at 15:11 GMT) |
| Unk (Mar 31, 2006 at 15:47 GMT) |
It sounds like due to the investment you have put into your current implementation that you are sort of set on your current implementation path... but I have to say that I am suprised you are not going with a more procedural method for generating these 3D backgrounds in addition to relying on the effects engine.
When I first played Lumines the backgrounds reminded me allot of the Demo Scene:
en.wikipedia.org/wiki/Demoscene
It would take some doing... but as I understand it, you can do allot in a very small space by building 3D models in-game which are made by re-using the same polys over and over making your memory footprint and asset directory very small.
Either that or I would start to extend the T2D vector graphics functionality to work more like flash... which would be more flexable if you want to make your backgrounds dynamic in any way.
Both of these approaches would be a considerable workload though unless you were able to recruit some people who have built these sorts of systems before.
Hrm... didn't someone integrate a flash player with Torque? Maybe you could attach it to a background layer? =P
Anyhow... I figure you have considered all this but just wanted to throw these ideas out there in case you are looking for a fresh perspective.
-Unk
Edited on Mar 31, 2006 16:38 GMT
| Jon Frisby (Mar 31, 2006 at 17:15 GMT) |
@Unk: The Flash player resource was put together with TGE in mind, but it might not be too hard to get it to work, however apparently it's been a source of problems for Venture Africa. Doing something like a "demo" is something I considered but it would just be too much labor that I couldn't do myself. For most skins, it just hasn't proven to be necessary -- my designer tends to work in photoshop so she's used to thinking of things in terms of objects and layers and such which maps quite well onto the capabilities that already exist in T2D. I've been doing a lot of programmatic animation in terms of things like rotations, fading and such but nothing that actually involves manipulating the texture. I'm still checking out t2dVector to see what it's capable of and how it interacts with it's environment but there may be some interesting possibilities there... It all depends on my designer's creative vision -- what she comes up with tends to dictate what I try to achieve.
-JF
| Phil Carlisle (Mar 31, 2006 at 20:48 GMT) |
Phil.
| Jon Frisby (Mar 31, 2006 at 21:11 GMT) |
At any rate, it's kinda moot for this particular skin as I've already paid for the work and I just don't have the budget to throw that work away.
It all comes down to resource allocation really. The approach you suggest requires a heavy investment of my time (in finding someone with the skills, integrating and testing their code, forward-porting it to new versions of the engine, etc), but that's just not a resource I have that much of.
There are other ways for me to reduce download size: Ship scaled-down assets (lower resolution or quality for videos, lower quality for audio), ship fewer skins in the demo, etc.
-JF
| Raxx (Apr 02, 2006 at 00:51 GMT) |
Looks like you've done your homework, I hope you find the best possible solution!
You must be a member and be logged in to either append comments or rate this resource.
