A players state is the data describing the value of all the variables pertaining to things which might happen in the game.
If that sounds like "blabla", it's because I was extra careful to word it unambiguosly, but it's probably failing utterly to communicate the basics of what I mean to describe.
So, let me give you an example: the players charactersheet in dungeons and dragons is part of the players state. Abstractly speaking, values which the player has not had a chance of influencing yet are also part of the player state; the lack of a level 20 ability on a level 10 character sheet can technically be thought of as part of the player state, because it is implied by the player state.
Now, as you can imagine, there's one heck of a lot of variables in the player state in a computer game: the player characters XYZ coordinates in the 3d space he inhabits, for example, are part of it.
All of these variables, together, form a cartesian product. A cartesian product is something usually used in math, but the short story is, it's a function, it's sometimes useful, and while it's definite, it's usually not finite, and it's not usually something you can picture in your head unless you're rather brilliant.
I bring it up, because understanding how to handle player state, as a game designer, inevitably ties in to handling the cartesian product: the cartesian product of the player state variables is the collection of all the possible permutations of all the variables.
If the variables were strength and agility, and those variables went from 1 to 3 each, the collection of permutations would be:
(str=1 agi=1,str=1 agi=2,str=1 agi=3,
str=2 agi=1,str=2 agi=2,str=2 agi=3,
str=3 agi=1,str=3 agi=2,str=3 agi=3)
Here, I've seperated each permutation with a comma.
That is, in other words, the cartesian product, and you can hopefully see what I mean when I say it is this product you need to keep in mind when designing a game...going by the above example, if the player only gets to level his stats twice, with a free choice between agility and strength, if you want to cover all your bases in a quest, you need to deal with both players who are 2str2agi, 3str1agi, and 1str3agi...since that's the possible player states at that time, supposing the player is forced to use level up points.
As you can see, all of these are present in the cartesian product above...the cartesian product, in other words, is the source of possibilities the player can expose the designer to, though it almost always contains permutations that couldn't happen at a specific point in a game.
Games are, by their nature, fun because they make manipulating the player state difficult. Handling player state, then, becomes a question of designing fun difficulties for the player. Thinking of the game designers job in this manner makes it seem ever-so-slightly sadistic, but regardless of what it seems like, it is what it is: You're out to stop the player from getting what he wants, to make him fight for it, and to (hopefully) make him beat you whilst he retains the illusion that you wanted to win too Which you didn't. But shh, lets keep quiet about that.
There's more to it than simply designing fun roadblocks though; you want the player to feel as though you are not limiting him, but rather, that he is limiting himself. For instance! the classic jump puzzle, while not very fun, makes the player limit where he walks because you punish him if he does do something else. Think of a room you as a player must walk across. If the state possible within the room is simply the entirety of the room floor, the room is boring. Clearly, where the player is able to walk has been limited by the designer. Put a chasm in the middle of the room, though, and have the player jump over the chasm or be forced to restart at the start of the room, and suddenly, both the player and you limit the player; see, the player limits himself by wishing to avoid the chasm. It doesn't really matter that you designed both obstacles; it doesn't matter if the chasm is a very small challenge to overcome...because it accomplishes the most important thing: the player is suddenly thinking in terms of what he wants to do, and what he wants to not do; not in terms of what you want him not to do.
Since we, as game designers, are forced to make sure our players don't do certain things (walk through our walls for example...he must stay on the path, as it were), it serves us well to try and design the fashion in which the player can change the player state in such a way that he inhibits himself, and thinks in terms of what he does and does not want to do. This, we do by making sure the player can be punished, if only ever so slightly, by being careless.
And that's really it; we should focus on making the hard edges in the player state soft, whereever possible...so instead of being constrained on a huge balchony, the player is on a huge balchony and part of the railing has come off so the player could possibly fall over, if he was careless.
This probably sounds...like a weird hypothesis, but I believe that this type of design is part of the reason Batman: Archam Asylum feels exceptionally free and open, in spite of being quite linear, and oftentimes quite constrained. The fact that you have choice, even if it's sometimes useless and clearly bad choice, it keeps the player making up his mind out the limits of the world, keeps him thinking...and that's really enough to make the player forget about the game designer and his artificial boundaries...
mandag den 28. december 2009
lørdag den 26. december 2009
Ancestry as a game element
The idea of bloodlines and ancestry - that one person is, merely because they were born from certain parents, important and carries within them a particular destiny is perhaps at the very root of elitism.
For that reason, I'd like to make the case that genetic (inherited) memory and will is an excellent concept for an interactive narrative.
Genetic memory can take many shapes and forms, but it's irremovably tied to ancestry - and your mum & pop. A person with person with a bloodline with genetic memory is, as a result, tied to his mom and dad. It could be further manipulated, such that only certain genders receive the full extent of the gift, as well as the ability to allow their children to inherit memory...these genders would not necessarily be set in stone, they could be alternating, or use some type of pattern, but the long and short of it is, a discussion of entitlement and strength can be brought into the narrative.
Genetic memory - which might be muscle memory, memory of crafts or meditative techniques, as well as memory of what has happened to every person in your bloodline coming before you - could be used as an excuse for attributing the players character with extraordinary abilities, and perhaps even the ability to converse with or be possed by his ancestors at his will or theirs.
It opens up many possibilities, but unlike so many, many stories, this one can be kept groomed - the Dollhouse TV series is doing something similar, but it's had a very difficult time getting going because it attempts high internal consistency, buffy the vampire slayer does it a bit, but only as a minor subplot, assasins creed does it, but doesn't use it for anything other than a starting point - and it's one of those "one magic thing" that people will accept in a narrative, yet it remains very specific.
When I say, one magic thing, it's because most stories only have one thing out of the ordinary - a focal concept. For example, if we were considering a world where everybody posses genetic memory, it wouldn't be "one magic thing" - it would merely be part of the setting. But take bumblebee in the transformers movie - it becomes sams car. We, as receivers, come to understand that we follow sam precisely because he is, through coincidence, fated to receive bumblebee. If it had come to someone else, the story would've been about them instead, not about sam.
Sam, however, cannot win the lottery the same day as he gets bumblebee, which would be another thing so unlikely that it would qualify as "the one magic thing". See, as unlikely as it is that a giant spacerobot becomes your car, it's part of the plot and the setting that it _must_ happen to _someone_ - the movie merely chooses to focus on the person it happens to.
But noone gets to be on the receiving end of two huge coincidences within the context of the same story - it's almost unheard of.
The thing about genetic memory is that it's not general, it's specific - it's not "magic", for example. If it had been magic...sure, our protagonist could have both magic and genetic memory if those things were tied together, being part of the same ability, but then, our protagonist would be much less predictable. Magic can do lots of things that the receivers of the story won't be able to predict; not so with genetic memory. It's nice and tight, but at the same time, presents a large amount of solutions.
So not only can it be used as the basis of a major narrative due to the relationships between characters the ability inherently projects and explains, it can also be used because it makes for interesting adventure and problem solving!
Now, notice that I say interactive narrative - I think this type of thing fits with narrative that allows choice particularly well, because ancestral preconceptions necessarily try to take choice away, and having a player deal with that seems like it could be almost existensial.
For that reason, I'd like to make the case that genetic (inherited) memory and will is an excellent concept for an interactive narrative.
Genetic memory can take many shapes and forms, but it's irremovably tied to ancestry - and your mum & pop. A person with person with a bloodline with genetic memory is, as a result, tied to his mom and dad. It could be further manipulated, such that only certain genders receive the full extent of the gift, as well as the ability to allow their children to inherit memory...these genders would not necessarily be set in stone, they could be alternating, or use some type of pattern, but the long and short of it is, a discussion of entitlement and strength can be brought into the narrative.
Genetic memory - which might be muscle memory, memory of crafts or meditative techniques, as well as memory of what has happened to every person in your bloodline coming before you - could be used as an excuse for attributing the players character with extraordinary abilities, and perhaps even the ability to converse with or be possed by his ancestors at his will or theirs.
It opens up many possibilities, but unlike so many, many stories, this one can be kept groomed - the Dollhouse TV series is doing something similar, but it's had a very difficult time getting going because it attempts high internal consistency, buffy the vampire slayer does it a bit, but only as a minor subplot, assasins creed does it, but doesn't use it for anything other than a starting point - and it's one of those "one magic thing" that people will accept in a narrative, yet it remains very specific.
When I say, one magic thing, it's because most stories only have one thing out of the ordinary - a focal concept. For example, if we were considering a world where everybody posses genetic memory, it wouldn't be "one magic thing" - it would merely be part of the setting. But take bumblebee in the transformers movie - it becomes sams car. We, as receivers, come to understand that we follow sam precisely because he is, through coincidence, fated to receive bumblebee. If it had come to someone else, the story would've been about them instead, not about sam.
Sam, however, cannot win the lottery the same day as he gets bumblebee, which would be another thing so unlikely that it would qualify as "the one magic thing". See, as unlikely as it is that a giant spacerobot becomes your car, it's part of the plot and the setting that it _must_ happen to _someone_ - the movie merely chooses to focus on the person it happens to.
But noone gets to be on the receiving end of two huge coincidences within the context of the same story - it's almost unheard of.
The thing about genetic memory is that it's not general, it's specific - it's not "magic", for example. If it had been magic...sure, our protagonist could have both magic and genetic memory if those things were tied together, being part of the same ability, but then, our protagonist would be much less predictable. Magic can do lots of things that the receivers of the story won't be able to predict; not so with genetic memory. It's nice and tight, but at the same time, presents a large amount of solutions.
So not only can it be used as the basis of a major narrative due to the relationships between characters the ability inherently projects and explains, it can also be used because it makes for interesting adventure and problem solving!
Now, notice that I say interactive narrative - I think this type of thing fits with narrative that allows choice particularly well, because ancestral preconceptions necessarily try to take choice away, and having a player deal with that seems like it could be almost existensial.
Progress on the conversation editor
Since I started working with off topic productions as the primary use case for the conversation editor project, much has happened with my plans.
As it turns out, the ideal tool has not been to handle persistence from within the context of the program itself, but rather, to merely load and save to file and have another program handle the persistence...it scales back the responsibility of the storyline editor considerably, but it also means that the writers will be stuck with generalized persistence management tools rather than custom tailored ones - at least for now.
We currently rely on an svn server to manage this - and in the future, if I do solve this problem with a custom tool, I will likely rely on the svn protocol. It works excellently with xml serialization, which is what we use now and what we'll be using going forward. There's an odd, but completely bearable, workflow currently tied to working with the program which is, currently, called Fabula.
The current Alpha version is done, but major refactoring has already commenced...the early focus has been on being able to model threaded conversations, which has been a success, but it's a far cry from what I eventually want to do. I'm afraid one of the things we will want is an emulator, which I will have to program after the next batch of minor changes has been implemented and refactoring is done. Fortunately, the theory behind everything is sound, and what I've used to program with is not likely to deprecate anytime soon...the only worry I could possibly have is that microsoft will deprecate WPF entirely, but that doesn't seem like it'll happen within 8-10 years.
As it turns out, the ideal tool has not been to handle persistence from within the context of the program itself, but rather, to merely load and save to file and have another program handle the persistence...it scales back the responsibility of the storyline editor considerably, but it also means that the writers will be stuck with generalized persistence management tools rather than custom tailored ones - at least for now.
We currently rely on an svn server to manage this - and in the future, if I do solve this problem with a custom tool, I will likely rely on the svn protocol. It works excellently with xml serialization, which is what we use now and what we'll be using going forward. There's an odd, but completely bearable, workflow currently tied to working with the program which is, currently, called Fabula.
The current Alpha version is done, but major refactoring has already commenced...the early focus has been on being able to model threaded conversations, which has been a success, but it's a far cry from what I eventually want to do. I'm afraid one of the things we will want is an emulator, which I will have to program after the next batch of minor changes has been implemented and refactoring is done. Fortunately, the theory behind everything is sound, and what I've used to program with is not likely to deprecate anytime soon...the only worry I could possibly have is that microsoft will deprecate WPF entirely, but that doesn't seem like it'll happen within 8-10 years.
søndag den 12. april 2009
Some stuff clutter has been used for so far
http://www.youtube.com/watch?v=arL_-tQndzI&feature=PlayList&p=9FAEABEC2B33B600&index=0&playnext=1
I slapped together a playlist on youtube of some videos that demonstrate applications slapped together with clutter.
If you're wondering why there aren't any more videoes outthere, the answer is simple:
Clutter is only about 2 years old, and Intel only purchased openedhand in september 08. It hasn't even been released in version 1.0 yet.
Perhaps of some interest is the fact that the iphone is also fully capable of running clutter applications, at least with regards to hardware. The same can be said for all symbian smartphones, and many of HTC's windows mobile smartphones, though again, it might not be easy to rig the software to allow it to happen.
But the important point is, if something is written using the clutter library it's not particularly constrained or encumbered by graphics hardware.
I slapped together a playlist on youtube of some videos that demonstrate applications slapped together with clutter.
If you're wondering why there aren't any more videoes outthere, the answer is simple:
Clutter is only about 2 years old, and Intel only purchased openedhand in september 08. It hasn't even been released in version 1.0 yet.
Perhaps of some interest is the fact that the iphone is also fully capable of running clutter applications, at least with regards to hardware. The same can be said for all symbian smartphones, and many of HTC's windows mobile smartphones, though again, it might not be easy to rig the software to allow it to happen.
But the important point is, if something is written using the clutter library it's not particularly constrained or encumbered by graphics hardware.
The theoretical case for using the clutter framework in an actual game
I've been trying to wrap my mind around the clutter framework and the accompanying technologies for a while now, because it seems to be a powerful library that makes a lot of features easily accesible.
What might not be apparent, is that the problem it solves - the rendering of 2d graphics - is a problem in the first place. So let's examine for a moment what it actually is: A library that utilizes opengl as a backend for drawing hardware accelerated graphics.
Why is hardware acceleration necessary for a 2d game in this day and age? I hear you cry.
Well have a look at this:
http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Early_debate
Excerpt from the linked section:
"By 1998, even the much-maligned S3 Virge was substantially faster than the fastest Pentium II running Direct3D’s MMX rasterizer."
The S3 virge, presumably, was an elcrapo graphics card with 4 megabytes of VRAM, that might've cost about 40$ to slap into your run-of-the-mill prefabbed consumer desktop computer at Dell or HP. The fastest Pentium II, by comparison, must've been about 6-700$ or so, not even available in preassembled computers unless specifically requested.
The perspective this is meant to impress upon you is this: Hardware acceleration rocks, software emulation sucks, and this has been the case since 10 years ago, with the gap in performance/price widening every quarter ever since.
Ok, so we need hardware acceleration for the graphics. How do we get that?
We use a library. Libraries are collections of functional code that performs operations detailed in an API. A library is different from a system call in that a system call is implemented in the operating system, whereas the library resides in a little bubble attached to the operating system. Indeed, it "talks" to other libraries and hardware as directed and permitted by the operating system.
Even Direct X, which is microsofts multimedia library, is in a bubble attached to the operating system. While it's true that you cannot run windows without having some form of direct x on your system, direct x is a library because it does not belong within the windows kernel. As such, it's a library in it's own right. Microsoft also includes a version of openGL with Windows.
So why not simply use Direct X or OpenGL? Why use a library build on top of another library?
Because OpenGL, for example, is very simple. It only allows a program you write to communicate with graphical hardware through some very rigid functions.
Textures are a common concept within graphics rendering; it's a bitmap projected onto a geometric shape. But to OpenGL, a texture isn't a file on disk; it's a bitmap in memory. Converting a file on disk into a bitmap in memory is a function which OpenGL does not provide. So you need to either program it yourself, or find another library which can be used to read files into memory in a way that makes the final result compatible with OpenGL.
But Mads, you say, surely there are 2d libraries with hardware acceleration other than OpenGL and Direct3d, which are, after all, predominantly 3d libraries?
No, no there are not. Yes, there are 2d libraries, but no, they do not have hardware acceleration. Look at the firefox browser you're probably using to browse this blog right now. It uses the Cairo library. It's not hardware accelerated, and it shows. That's why web browsing is so processor intensive compared to how piss poor the graphics are. The responsiveness of the firefox webbrowser is _not_ good enough that the same kind of thing would go over well in a game.
So, clutter. It's a library that supports text rendering (which is a motherfucking bitch to implement yourself), textures (as in, you can load them from disc and manipulate them using an established framework), and fluid animations, all in an easy-access framework. It's also brand spanking new. And it's primarily a 2d rendering library, but perfect for working with many layers and grouped things because it has a scenegraph and a z axis thingie.
Sure, it's meant for designing interfaces, but that doesn't matter; if it's hardware accelerated, performance will probably be up to snuff. It even supports rendering of videos onto textures, and yes, this can be hardware accelerated as well.
About system requirements:
On ebay, for less than 200$, an eee pc 4g, the lowest performance eee, can be had. It's intel GMA900 graphics card can hardware accelerate opengl 1.4 - which is what clutter uses. Now seeing as intel owns openedhand, the developer behind the clutter library, this should hardly come as a suprise - the intel GMA 900 and above almost exclusively make up the graphics hardware in netbooks, and intel purchased openedhand with the intent of using clutter for rendering the UI on it's moblix platform....which is the operating system designed to push netbooks and mobile internet devices developed by intel.
Making clutter run well on the GMA900 and above, as a concequence, is likely a high priority at openedhand...
This implies that clutter will be a future-proof rendering option for a 2d game, and it also means that any 2d game written with it will likely perform well even on future mobile internet devices. Oh, and it's a cross platform library, of course, so games written with it run both on windows, linux and mac os x.
But if running on tiny, low performance netbooks isn't good enough, the first geforce graphics card to support opengl 1.4 is geforce 4, ti4600, which was the top of the line model back in febuary 2002. Every geforce model since 5xxx and forward has supported it as well. Same goes for every radeon including and above the 9500, which is also ca. 2002.
It's also likely that most laptops support it, though it's difficult to say because laptop gpu's are considerably worse documented; but anything both nVidea and ATI have been shovelling into laptops since 2004 ought to support clutter, and it's supported on _all_ of intels graphics hardware.
Finally, about licensing: Clutter, and all libraries it uses and works with, is released under LGPL. This means that it's legal to build proprietary software using the library, but that anyone who does so, ideally, allows people to upgrade to new versions of the libraries used if they want. I haven't figured out how difficult this aspect might be, yet, but I don't foresee any problems.
What might not be apparent, is that the problem it solves - the rendering of 2d graphics - is a problem in the first place. So let's examine for a moment what it actually is: A library that utilizes opengl as a backend for drawing hardware accelerated graphics.
Why is hardware acceleration necessary for a 2d game in this day and age? I hear you cry.
Well have a look at this:
http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Early_debate
Excerpt from the linked section:
"By 1998, even the much-maligned S3 Virge was substantially faster than the fastest Pentium II running Direct3D’s MMX rasterizer."
The S3 virge, presumably, was an elcrapo graphics card with 4 megabytes of VRAM, that might've cost about 40$ to slap into your run-of-the-mill prefabbed consumer desktop computer at Dell or HP. The fastest Pentium II, by comparison, must've been about 6-700$ or so, not even available in preassembled computers unless specifically requested.
The perspective this is meant to impress upon you is this: Hardware acceleration rocks, software emulation sucks, and this has been the case since 10 years ago, with the gap in performance/price widening every quarter ever since.
Ok, so we need hardware acceleration for the graphics. How do we get that?
We use a library. Libraries are collections of functional code that performs operations detailed in an API. A library is different from a system call in that a system call is implemented in the operating system, whereas the library resides in a little bubble attached to the operating system. Indeed, it "talks" to other libraries and hardware as directed and permitted by the operating system.
Even Direct X, which is microsofts multimedia library, is in a bubble attached to the operating system. While it's true that you cannot run windows without having some form of direct x on your system, direct x is a library because it does not belong within the windows kernel. As such, it's a library in it's own right. Microsoft also includes a version of openGL with Windows.
So why not simply use Direct X or OpenGL? Why use a library build on top of another library?
Because OpenGL, for example, is very simple. It only allows a program you write to communicate with graphical hardware through some very rigid functions.
Textures are a common concept within graphics rendering; it's a bitmap projected onto a geometric shape. But to OpenGL, a texture isn't a file on disk; it's a bitmap in memory. Converting a file on disk into a bitmap in memory is a function which OpenGL does not provide. So you need to either program it yourself, or find another library which can be used to read files into memory in a way that makes the final result compatible with OpenGL.
But Mads, you say, surely there are 2d libraries with hardware acceleration other than OpenGL and Direct3d, which are, after all, predominantly 3d libraries?
No, no there are not. Yes, there are 2d libraries, but no, they do not have hardware acceleration. Look at the firefox browser you're probably using to browse this blog right now. It uses the Cairo library. It's not hardware accelerated, and it shows. That's why web browsing is so processor intensive compared to how piss poor the graphics are. The responsiveness of the firefox webbrowser is _not_ good enough that the same kind of thing would go over well in a game.
So, clutter. It's a library that supports text rendering (which is a motherfucking bitch to implement yourself), textures (as in, you can load them from disc and manipulate them using an established framework), and fluid animations, all in an easy-access framework. It's also brand spanking new. And it's primarily a 2d rendering library, but perfect for working with many layers and grouped things because it has a scenegraph and a z axis thingie.
Sure, it's meant for designing interfaces, but that doesn't matter; if it's hardware accelerated, performance will probably be up to snuff. It even supports rendering of videos onto textures, and yes, this can be hardware accelerated as well.
About system requirements:
On ebay, for less than 200$, an eee pc 4g, the lowest performance eee, can be had. It's intel GMA900 graphics card can hardware accelerate opengl 1.4 - which is what clutter uses. Now seeing as intel owns openedhand, the developer behind the clutter library, this should hardly come as a suprise - the intel GMA 900 and above almost exclusively make up the graphics hardware in netbooks, and intel purchased openedhand with the intent of using clutter for rendering the UI on it's moblix platform....which is the operating system designed to push netbooks and mobile internet devices developed by intel.
Making clutter run well on the GMA900 and above, as a concequence, is likely a high priority at openedhand...
This implies that clutter will be a future-proof rendering option for a 2d game, and it also means that any 2d game written with it will likely perform well even on future mobile internet devices. Oh, and it's a cross platform library, of course, so games written with it run both on windows, linux and mac os x.
But if running on tiny, low performance netbooks isn't good enough, the first geforce graphics card to support opengl 1.4 is geforce 4, ti4600, which was the top of the line model back in febuary 2002. Every geforce model since 5xxx and forward has supported it as well. Same goes for every radeon including and above the 9500, which is also ca. 2002.
It's also likely that most laptops support it, though it's difficult to say because laptop gpu's are considerably worse documented; but anything both nVidea and ATI have been shovelling into laptops since 2004 ought to support clutter, and it's supported on _all_ of intels graphics hardware.
Finally, about licensing: Clutter, and all libraries it uses and works with, is released under LGPL. This means that it's legal to build proprietary software using the library, but that anyone who does so, ideally, allows people to upgrade to new versions of the libraries used if they want. I haven't figured out how difficult this aspect might be, yet, but I don't foresee any problems.
mandag den 6. april 2009
The Spy Blimp
I might try to draw up some sketches at some point, but for now, I want to document a concept here for posteritys sake.
Spy blimps are a whole world of awesome. I spent an hour or so designing a particularly cool one in my head. Well, to me it's particularly cool.
See, blimps have always been fascinating to me...it's one thing to fly, but it's quite another to remain airborne. A propeller airplane is little more than a bird - it can get about much faster than walking or jumping, but it's still severely constrained. What goes up must come down and all that.
I've never been in one though...closest thing I've been in was an airglider airplane - a plane flying on airstreams, very light, requirering no engine...but, while capable of flying quite far, they must keep in motion, must maneuver with the wind, must...well, you get the picture. They're inhibited.
Air baloons, I suppose, are kindof cool too....in the same way hitchhiking is. You never know quite where you end up, but at least you're getting somewhere. It's, again, ihibited.
Not so with blimps. Blimps can remain airborne for as long as they want, like air baloons, but they can go places, like airplanes....Perfect!
Well, when I say blimp, it's because DARPA has been contracted for something the popular news outlets call a spy blimp...what I really thought up is an awesometastic derrigible. See, a derrigible has an internal construction and an internal structure, and the outer coating is not a balloon itself...rather, it's just there to cover the structure of the craft against the elements. Indeed, large derrigibles can be thought of as assemblies of helium or hydrogen balloons, embued with other properties (and engines!).
Large derrigibles are powerful, and are able to lift quite a lot of weight, but the classic ones are run on hydrogen as carrier element, which is highly volatile. The Hindenburg, greatest airship ever made (...somewhat similar to the titanic, greatest passenger craft ever made....) failed on it's virgin journey.
...and, at this point, I realize the irony of scribbling an idea down and the scribbling taking so long that I'm no longer in the mood for it when I just get to the important bits.
But fuck it:
Use carbon nanotube firbres for the internal balloons, rigid enough to maintain shape even when pumped empty of air
vary balloon displacement by means of nanotube fibre patches that can vary in length when electricity is applied
stick solar panels up top
use two dirrigibles side by side with a bridge inbetween
allow dirrigibles to alter outside shape from fairly air-streamlined to completely boxy in order to be rader invisible, using light tent-like material
coat the entirety of the bottom of the airship in blue-grey-black epaper for live action visual cammouflage
built a greenhouse on the bridge section for food
keep stock of new rapid-delivery lithium-ion batteries as those developed at MIT for rapid electricity availability at all hours (fast enough to power laser cannon batteries or railguns - stuff with infinite ammo...probably run dry in 4-5 shots, but hey, laserguns are LIGHT)
keep weight ratio low to be able to go higher than all jet engine missiles and hopefully out of range of rockets using supperior carbon-nanotube balloon goodness
Keep giant kites in top compartments for blazing speed on the jetstream (and maybe even for powering wind turbines...the sun may be blotted out by dust, but the winds will never cease, and ultra violet rays can grow foods! mm mm good)
Ok I think that's all my crazy ideas, for now...more, better, later.
Spy blimps are a whole world of awesome. I spent an hour or so designing a particularly cool one in my head. Well, to me it's particularly cool.
See, blimps have always been fascinating to me...it's one thing to fly, but it's quite another to remain airborne. A propeller airplane is little more than a bird - it can get about much faster than walking or jumping, but it's still severely constrained. What goes up must come down and all that.
I've never been in one though...closest thing I've been in was an airglider airplane - a plane flying on airstreams, very light, requirering no engine...but, while capable of flying quite far, they must keep in motion, must maneuver with the wind, must...well, you get the picture. They're inhibited.
Air baloons, I suppose, are kindof cool too....in the same way hitchhiking is. You never know quite where you end up, but at least you're getting somewhere. It's, again, ihibited.
Not so with blimps. Blimps can remain airborne for as long as they want, like air baloons, but they can go places, like airplanes....Perfect!
Well, when I say blimp, it's because DARPA has been contracted for something the popular news outlets call a spy blimp...what I really thought up is an awesometastic derrigible. See, a derrigible has an internal construction and an internal structure, and the outer coating is not a balloon itself...rather, it's just there to cover the structure of the craft against the elements. Indeed, large derrigibles can be thought of as assemblies of helium or hydrogen balloons, embued with other properties (and engines!).
Large derrigibles are powerful, and are able to lift quite a lot of weight, but the classic ones are run on hydrogen as carrier element, which is highly volatile. The Hindenburg, greatest airship ever made (...somewhat similar to the titanic, greatest passenger craft ever made....) failed on it's virgin journey.
...and, at this point, I realize the irony of scribbling an idea down and the scribbling taking so long that I'm no longer in the mood for it when I just get to the important bits.
But fuck it:
Use carbon nanotube firbres for the internal balloons, rigid enough to maintain shape even when pumped empty of air
vary balloon displacement by means of nanotube fibre patches that can vary in length when electricity is applied
stick solar panels up top
use two dirrigibles side by side with a bridge inbetween
allow dirrigibles to alter outside shape from fairly air-streamlined to completely boxy in order to be rader invisible, using light tent-like material
coat the entirety of the bottom of the airship in blue-grey-black epaper for live action visual cammouflage
built a greenhouse on the bridge section for food
keep stock of new rapid-delivery lithium-ion batteries as those developed at MIT for rapid electricity availability at all hours (fast enough to power laser cannon batteries or railguns - stuff with infinite ammo...probably run dry in 4-5 shots, but hey, laserguns are LIGHT)
keep weight ratio low to be able to go higher than all jet engine missiles and hopefully out of range of rockets using supperior carbon-nanotube balloon goodness
Keep giant kites in top compartments for blazing speed on the jetstream (and maybe even for powering wind turbines...the sun may be blotted out by dust, but the winds will never cease, and ultra violet rays can grow foods! mm mm good)
Ok I think that's all my crazy ideas, for now...more, better, later.
fredag den 3. april 2009
Virtual Machines, Python, Clutter and Ubuntu
...I'm slowly making progress while working on my dialogue editor project.
In working with my first open source project, I'm finding that a lot of exceptional effort goes into the system - and that it's really quite elegant.
But it's also a bit of a nuisance...which I can mostly attribute to my own expectations and background. See, I've always considered myself more of a visitor whenever I've used linux, not an actual, permanent user. I've found many neat features in it, many that I'd increasingly like to combine with my windows rig - but it's only on this project that I've come to the conclusion that serious programming will often necessitate that you do it from a 'nix system.
See, I came accross this excellent UI framework called Clutter, being developed by openedhand. It's drawn using OpenGL for some parts, but native operating system rendering for fonts. And it has bindings such that it can be used from python.
Most UI libraries will give you one or two of these - an extensive library of premade functionality, excellent text rendering, hardware accelerated graphics rasterisation, and an elegant application programmer interface.
Clutter gives all 4. It's also a so-called copyleft licence, meaning that code which uses clutter can be proprietary if need be; but any modifications of clutter itself need to be published as either gpl or lgpl.
So it's great and all, but there is a catch. Clutter is a bitch to compile because it requires a lot of other libraries as binaries...and of course, neither clutter itself, nor the other libraries, are available as binaries on windows.
Enter VMware Player by VMware, and a virtual machine, called a virtual appliance, with ubuntu installed.
I managed to get it up and running in the course of about 4 hours....and that's on linux.
Like I said, it's a bitch. But now, it's all up and configured on the virtual machine, so work can soon begin...I do need to build a production pipeline soon, though, such that I can do test-runs on the native host machine, which is the next thing I'll be doing, and from there, well...hopefully, I'll link the virtual machine up with a repository, and have it run a virtual file server of compiled binaries....and _then_ I'll be able to work on the actual application =P
In working with my first open source project, I'm finding that a lot of exceptional effort goes into the system - and that it's really quite elegant.
But it's also a bit of a nuisance...which I can mostly attribute to my own expectations and background. See, I've always considered myself more of a visitor whenever I've used linux, not an actual, permanent user. I've found many neat features in it, many that I'd increasingly like to combine with my windows rig - but it's only on this project that I've come to the conclusion that serious programming will often necessitate that you do it from a 'nix system.
See, I came accross this excellent UI framework called Clutter, being developed by openedhand. It's drawn using OpenGL for some parts, but native operating system rendering for fonts. And it has bindings such that it can be used from python.
Most UI libraries will give you one or two of these - an extensive library of premade functionality, excellent text rendering, hardware accelerated graphics rasterisation, and an elegant application programmer interface.
Clutter gives all 4. It's also a so-called copyleft licence, meaning that code which uses clutter can be proprietary if need be; but any modifications of clutter itself need to be published as either gpl or lgpl.
So it's great and all, but there is a catch. Clutter is a bitch to compile because it requires a lot of other libraries as binaries...and of course, neither clutter itself, nor the other libraries, are available as binaries on windows.
Enter VMware Player by VMware, and a virtual machine, called a virtual appliance, with ubuntu installed.
I managed to get it up and running in the course of about 4 hours....and that's on linux.
Like I said, it's a bitch. But now, it's all up and configured on the virtual machine, so work can soon begin...I do need to build a production pipeline soon, though, such that I can do test-runs on the native host machine, which is the next thing I'll be doing, and from there, well...hopefully, I'll link the virtual machine up with a repository, and have it run a virtual file server of compiled binaries....and _then_ I'll be able to work on the actual application =P
Abonner på:
Indlæg (Atom)
