The linux community has rallied behind causes we felt were worth supporting in the past, however I cannot remember any instance in which the community has rallied behind a commercial venture before.
Wouldn't it be more logical to put your
donation into one of the open source game projects? I mean, that way even if the whole
effort goes to the waste bin, at least you still
get the source code...
Why does all open source software tend to have bad user interface?
Two reasons: First, because most folks *capable* of _creating_ a decent GUI are by definition competent enough to use the command line interface. Second, because people who are *that* dependant on the _graphical_ interface are too damn freaked by the commandline nature of compilers that they don't do anything about it.
Short answer: Either get used to the commandline or be friggin' brave enough to make the GUI better.
And for GOD sakes, some of the BEST software has ONLY a commandline interface, so NEVER equate commandline interfaces with commandline interfaces. Hmph!!!!!
It is true that a few companies built around a loss-leader business model have used open-source software as their loss leader, and have failed to recoup their losses and thus gone out of business. The open-source development model has as one of its strengths that it is not vulnerable to the failure of anyone's business model.
*Very* well said. This is an excellent addressment of this issue. Frater, you should develop this into a full length essay, as it places the issue in its proper context. Failure of businesses is perpendicular to the issue of free software success.
The distributed server thing ala peer-2-peer for online playing is a great idea! Have each server be a land or portion of a land and you must pass through some kind of gate to move to the next server or perhaps cross some mountains, or take a boat ride, or enter some caves etc.
Yes, this is an idea that many have floated
before, in various guises, over the years at
WorldForge, and because of that I would have to
bet that when we're further along, people will
experiment with doing that. In fact, we're
planning to put the hooks in to allow people to
experiment with this into our next version of the
server.
Now, there's a lot of issues to deal with in
such a situation, but heck, that's what
experimentation is all about, and it wouldn't be
fun without some challenges, right?;-)
It's impressive to see how quickly everyone
is grokking what WF is about! And you know
you're all welcome to come join in the fun with
us, there's plenty of interesting work to go
around.
While it would be nice for people to have personal sattelites, the space junk would be horrible.
First of all, understand that the trajectories
of every one of these is going to be calculated
and tracked, so the chance of anything running
into it during its lifetime will most assuredly
be nil.
Second, these will be launched into a low
earth orbit that has a relatively high rate of
orbital decay due to atmospheric drag. Yes, there
actually is a *little* bit of atmosphere at the
height that these sats will be orbiting.
So, the worry about space junk is probably
not warrented here. Yeah, these little
contraptions will be "in the way" for a while,
perhaps a dozen years, max, before they eventually
re-enter the atmosphere and burn up.
The biggest worry with "space junk" is stuff
that is at a higher altitude where it *won't*
decay, or things that are untrackable (such as
loose screws, bits of metal from explosive bolts,
etc.)
What if there were a craft that could sweep the heavens? Would it use a free-electron laser to destroy the bulk of the craft? Would it be similar to a whale? A giant craft that takes in a region of space and filters out the crud from the vacuum?
Nice idea, but it's tons cheaper just to track
what junk is already up there, and try to avoid
creating more (or create it in orbits that will
naturally decay with time). Besides, a craft
able to maneuver and collide with such items
would pose a risk of colliding with something and
sending forth additional slivers of metal, paint
flecks, and etc. Not to mention that it'd need
tons of fuel in order to do all the required
manuevering.
Linux has had to build itself up from the ground
without being able to rely on commercial groups
to make the software it needs.
Why should games be any different? If the
commercial developers won't make games, then we're
going to have to do it ourselves, just like much
of everything else in Linux.
As a blatant plug for my own project, this is
exactly what we at WorldForge
are shooting for. Good, free games targeted to
Linux (with Windows ports being secondary.) If
you want to see more Linux games, with the added
benefit of being free and open, then lend a hand.
Oh yeah? It is relatively simple to do something that has 3D, is networked and multiuser.. but if you are going to do something that is intended to be good and you want people to actually use the system you have a really big project on your hands...
Just from the top of my head: WorldForge, Metaverse, Verse etc.. Maybe it would be wiser to see how they are doing and choose to join on of them.
*Looks up*
Yup, WorldForge is quite far enough along to
give a project such as this a major leg up, and
we would be thrilled to collaborate with this
project (or any project) working on virtual world
types of things.
Even though us at worldforge don't speak of it
a whole lot, I think we often give thought to how
what we are doing could evolve into a virtual
reality like system - distributed server
clustering, in-game editing / building, player
uploaded media, client-side scripting... All
features that would be *critical* for a virtual
reality-based system.
Anyway... so even though our goals are being
thrust in a medieval direction, the architecture
is generic and usable for a variety of things,
and certainly should lend itself as a low level
base for non-game applications too.
When I was young, the incentive I had to learn
programming was so I could write games (yes, this
was back in the days before spreadsheets and
word processors *grin*). But what *really* got
me well educated was when I found out about net
projects doing open source development. Being
able to get mentorship from experts online, and
getting their direct review of your code, is
a very effective way to learn new technology very
well.
Times change, but not that much... I would
have to suspect that there is still some urge
to learn programming because of interest in games.
And I definitely know that net projects are
*still* one of the best ways to pick up new
technology.
If this is in fact the case, then one of the
best ways to promote education of free programming
could be encouraging young folks to work on the
various free game development projects out there.
Fringe benefit: One day maybe getting more free,
open source games that YOU can play.;-)
And I'm not just spouting opinion here... I
myself devote time to one of these game projects
(www.worldforge.org), helping people learn about
game programming, and I'm also participating in a
project to author and promote free, open source
textbooks (freebooks.myip.org).
If you have a few hours each week you can
devote to helping one of these projects by helping
teach or review people's code (or art!) and give
good feedback, that would certainly be one of the
best ways you can encourage learning of open tech.
And if you need to learn some of this stuff your
self and can afford a bit more time, well sheesh,
do yourself a favor!;-) And
in any case, participating in free communities is
a lot of fun, and can be very rewarding
personally. And of course it is the Right Thing
To Do.:-)
If anyone wants to leave questions about it here, I'll answer them later today, and pass them on to RMS.
Actually, I have a couple questions, although they're more philosophical than legal or technical. I'm running a project to create an online roleplaying game system, with source code under the GPL and all of the art, music, and game content released under the GPL and GFDL. The ideal we've chartered for ourself is the promotion and facilitation of Free Game Development, in the same spirit as the FSF promotes Free Software Development.
Yet it has come to our attention that guaranteeing the freedom of our source code will be difficult. On several occasions we have been approached by individuals wishing to make use of our code and media for commercial purposes, and have stated emphatically that they "cannot" release the contributions they would make (for the usual reason given - because they feel they couldn't make money otherwise). Now, the uncomfortable fact is that either through dynamic linking or through the "ASP loophole", they can run our server code with their additions and charge for access without ever releasing a line of their added code, as nothing legally or technically exists to prevent that.
But in discussing this with the other WorldForge developers I'm not so certain that there *should* be technical or legal preventions against this, for various reasons including one I'll outline in more detail below. The question I have been wondering and that I would like to get yours' and RMS' viewpoint on is whether or not we *should* be concerned about this? Since the GPL appears to allow keeping code secret either by not distributing the binaries, or by dynamically linking it, does this mean that it is morally okay to do so?
What I worry is that if it is possible for individuals to take advantage of our code and not have to share their own contributions back, it may stifle the free environment we are attempting to establish. I suspect that if sharing was required, then assuming all commercial
participants follow this rule the competition would be fair. However if it is possible to hold parts of the game system proprietary, then it will be seen (rightly or wrongly) as a competitive advantage to do so, and thus in spite of all the problems we all KNOW are intrinsic in hiding source code, they will take this route instead.
Without the use of legal or technical means of ensuring the freedom, it would appear that we would need to fall back to reliance on "peer pressure" and tradition to ensure sharing of code.
E.g., "blacklisting" companies that choose to use one of the loopholes.
Now, there is a side issue and a second question which is, I suppose, one of the issues peculiar to games. While with "normal" software there is usually little or no reason to prevent ALL of the code, documentation, and content from being released openly, with entertainment software it is sometimes desired to keep parts secret not for commercial reasons but instead to preserve some degree of mystery. One might argue that with a book, one is expected to read the pages in order and not cheat by reading the last page, however book reading is a solitary endeavor; this would be more akin to browsing through the poker deck when your partner is off buying beers. Now, there are many arguments and counterarguments on both sides that can be made. But here is the question: Does the need for hiding source code for purposes of ensuring mystery pose a legitimate exception to the free software / open source principles?
The approach we at WorldForge have been toying with is providing for "softcode" additions to the game, which are stored in a database and kept segregated from the primary game code, rather than encouraging use of the "ASP loophole" or dynamic linking loophole as workarounds. There are of course performance issues implied in using scripting rather than hard code, but we like this because it discourages hiding "too much" code.
Now, I hope our concerns are not dimissed because "it's just a frivolous game". Game software can and has been used for many purposes outside of entertainment, including education, visualization, and communication, and the issues outlined above will be of critical importance in assuring that these non-game applications of the software can enjoy the same freedom that the original code is being given.
The
Freebooks Project was started a few weeks
ago from an article here on Slashdot about
Free/Open Source Physics (or other scholastic) Textbooks. The author of that article,
Ben Crowell, proposed and helped start this
project.
We decided that since our interests had more
to do with the idea of writing free books than
writing physics books, that we'd write a free book
*on* writing free books.
Even though we've only had a few weeks, we've
got many of the technical hurdles tackled and are
getting down to collecting thoughts and ideas,
brainstorming, and filling in the website. And
if you're interested in lending your support to this cool (and critically needed) service to the
open source and free software communities,
check out
the site, and join our mailing list.
When Galileo was built, NASA put a Big Huge
Beefy antenna on there, that would deploy like
a flower bloom, and provide Lotsa Data.
Now, this is a directional antenna - it puts
out lots of data but only in a narrow cone. So
they needed a backup antenna, for when the main
one was not deployed or if it was not pointed
right, just for basic communications (i.e.,
"Galileo, point main antenna towards earth").
So this antenna is omnidirectional but very small
bandwidth (since you don't need bandwidth, after
all.)
Yeah, the big one broke. So they have to use
the dinky one for all the _data_ communication,
too.:-P
This would be like your monitor burning out
and having to figure out a way to use your
PC speaker to do file management.
Been used for years in aerospace
on
3D Printers
·
· Score: 2
I've seen this used for years in the space
industry. We used them for rapid prototyping.
We would design a spacecraft, drawing it all up
in 3D in CAD, then transmit the CATIA file over
to the stereolith dept, who would process it over
night to create the spacecraft.
There were some little drawbacks and quirks.
The plastic is a bit flimsy, so in order to have
arms (such as the ones that deploy the solar
array wings) someone needs to edit the 3D CAD
file to remove those bits, and after the model is
created, to put metal wires in and glue things
together.
In fact, in the hands of a good plastic model
builder with a few week's time, some pretty
incredible results can be achieved. One
spacecraft we designed had a really tricky
maneuver and deployment sequence, and our model
maker took time to put in the rotational
mechanics so that we could use the model to play
around with how this would work. (Sometimes
when you can play with a real toy you can figure
stuff out in a LOT less time than if it was only
in your head or a whiteboard.)
I worked on one of the concepts that lead up to
this design when I was working at TRW. There
were a number of different issues which made this
propulsion system pretty unique and challenging.
First, the sheer size of the thing... There
have been few (if any) spacecraft propulsion
systems this big and this powerful put up into
space.
Second is human safety. Take a look at the
rendering and you'll see an access port running
down between the two "ears". The shuttle docks
there and the astronauts traverse it. Obviously,
there are concerns about contaminates getting
in there... There were questions about whether
to pressurize this corridor or not - if it has
to hold a pressurized environment, then it would
end up being MUCH more expensive than if it
wasn't. On the other hand, having to suit up to
go from the station to the shuttle is a hassle
and introduces other kinds of risk.
Third was refuelability. We considered
whether to have a system that could be refilled
on orbit, versus one where one entire 'ear' is
pulled off and brought back to earth for
refurbishment. Obviously, there are pros and cons
each way. One interesting issue is fluid
depletion: If there was a problem with the
system, you may need to vent out the tank
contents before being able to refill it or take
it home - so we have to be careful that whatever
chemicals are ejected won't corrode or
contaminate anything. It looks like they
decided to go with a hydrazine monoprop system,
which is very safe, but has less performance than
other options, and thus will require more trips
by the shuttle.
It's interesting and a bit disappointing that
NASA has chosen to stick with Boeing even after
they failed so badly with the first design. Could
have been a great opportunity for some other
companies to get into the human rated spacecraft
market. Ah well...
I hate to call this bogus, but the article's
author is clearly clueless about chemistry, and
is implying things that just can't be.
I used to size tanks for storing various fluids
and gases, including Nitrogen. Yes, it is true
that you can get useful work out of pressurized
nitrogen. But the *amount* of work is rather
miniscule. We sometimes used pressurized
nitrogen as a rocket propellant, but only because
it was such a safe, predictable fuel; the
performance was a tenth of what you could get
with conventional chemical rockets (even rockets
burning gasoline.)
The article draws a comparison with batteries.
With batteries, they may not hold a lot of
energy, but you can recharge them. With gas,
the depressurization process is essentially
on-way. Getting energy back into a nitrogen
pressure vessel is just too hard.
Of course, then there's the danger...
I can't help feeling that NASA has got its priorities all mixed up. It keeps going for all these high cost, high risk mission to far flung places on the pretext of searching for evidence of life.
As cool as this may be I think they would be better of plowing more money into a replacement for the shuttle, possibly a return to the moon, and the ISS.
An interplanetary mission will run for on the
order of hundreds of millions (or less, during
the Faster/Cheapter/Better bargain days.) On the
other hand, Shuttle/ISS/Moon manned endeavors run
out into the tens of billions of dollars. Look
at the cost of a single shuttle mission. Ow.
NASA is obsessed with shooting big, dumb rockets at long distance targets at hugh cost.
There's a reason why they use expendable
launch vehicles: Launching a spacecraft on the
shuttle is just too dang expensive. Not just
because the Shuttle is an expensive launch
vehicle (it is), but because anything that is
launched must be checked umteen ways to Saturn
to make sure it's TOTALLY SAFE. Anything that
risks astronauts' lives - even in the slightest -
is a major, major no-no. Lower risk equals higher
cost, of course.
So in fact, in terms of return-on-investment,
the missions to far flung places are really a
small drop in the bucket compared with anything
that has to do with the shuttle. And using the
"big dumb boosters" (dumb?) really is the most
cost efficient, reliable way to go (at least for
now).
I do like the concept of electronic distribution and micropayments, but what's "micro" about these? I think this one is just capitalising on the brief novelty most people see here.
Well, but it proves the model, and that is a
very important thing. Success breeds success, and
with King successful, other writers are going to
give it a shot. Yeah, other authors won't have
the ready fame to leverage, but they know this,
and that makes them realize that they might need
to be a bit more creative in how they achieve
their aim. King has done the good deed of
nailing down the high end. Expect that others
are going to be exploring the lower ends. I
betcha we see a bunch of different models brought
forth over the next year or two. I'm sure people
will find the best one.
I worked on a team that did one of the concept definition for this mission (I designed the propulsion system), for TRW's proposal to build this spacecraft. (Guess we didn't get it, eh?)
Pluto/Kuiper Express (PKE) was to be one of three JPL solar system exploration missions. The other two include Europa Orbiter (intended to determine the existance of a subsurface ocean), and Solar Probe (intended to determine the origin of the solar wind). PKE's purpose was to image Pluto and Charon (Pluto's moon) and a Kuiper Belt object. EO's biggest challenge is it's complex orbit insertion. SP, of course, has to deal with an intense thermal environment.
PKE's principle challenge was to reliably conduct an autonomous encounter navigation after spending 8 years travelling out there. The craft would be zipping past Pluto at a good clip, and clicking a few pictures (for later transfer back to earth) would be tricky - gotta have the camera pointed in just the right directions at just the right time.
The reason autonomy is necessary, is that at Pluto, the round-trip time for a beam of light to travel between Pluto and ground control is 8 hours, but the entire Pluto encounter only lasts a few hours.
Another problem, mentioned in the article, is that finding a launch vehicle with sufficient performance to get enough mass (a few hundred kg's) going on an accurate trajectory, is pretty tricky.
I think it'd be a pretty cool mission, although I can understand why NASA may prefer to direct their funds towards other projects that would return larger amounts of results for less risk. I hope this doesn't mean Europa Orbiter or Solar Probe are also in danger of cancellation.
I am a spacecraft propulsion systems engineer, so I'm one of the guys that designs the satellites that go on top of these launch vehicles.
There is already a scary glut of launch vehicles today. The manufacturers had been forcasting a lot of demand, based on the expected success of Iridium. Iridium is a constellation system, which requires lots and lots of launches, as compared with single-launch satellites like the ones the Sea Launch puts up.
So... When Iridium went bankrupt, we saw an immediate evaporation of interest in constellation systems. Very simply, investors don't want to take the risk. Sometimes the systems have been reformed as non-constellation systems, or lumped onto other satellites, and other times they're simply cancelled. In any case, the net result is the same: The projected large market for launches is vanishing rapidly.
I think all of us know that the way to get low per-widget costs is to make a lot of them. Henry Ford proved this out with his affordable mass produced cars. And we all know that when you write a piece of software, the more customers you can sell to, the wider you can spread your development costs, and the lower a price you can charge and still make profit. Competition is a great way to drive costs down, but doing it in volume is an even better way.
So I don't know, maybe there will be a "clearance sale" or some such, but I *think* the result ain't going to be what we'd like. Having more launchers is fine, but what we *really* need are a lot more launches. Nothing else is really going to drive costs down to where we need them, IMHO.
OT Q: Why rewrite the server in C++, when you can continue to use the existing Python server? Profile the code, determine where the real speed issues are, and re-code those passages in C++. That way, you'll get the best of both worlds: the speed of programming in Python with the speed of execution of compiled C++.
Good question. The basic answer is that the speed of programming in Python isn't as valuable to us for this particular application. The stuff that isn't performance critical also happens to be the simpler bits of the program, so even if it is a bit harder to do in C++ than in Python, it doesn't matter all that much in the grand scheme. Plus, having the entire core written in one language is nice for simplification and elimination of interfaces (and the overhead).
What we'll probably end up with is the server's core in C++, and pluggable modules that can be written in Python or whatnot to implement some of the game-specific stuff. That way, the C++ will be limited to the areas that maintainers and future game developers won't be getting into very often.
This type of game most definitely falls into WorldForge's charter (www.worldforge.org), so if you're interested in developing something along these lines, you'll likely want to check us out, and maybe join us in the fun.
WorldForge's core technology is being developed to be game-generic. Present plans include multiplayer RPG and RTS games. We've nothing against violence in video games, but in most of the games we have planned right now it plays a lesser role than in commercial games. We value problem solving and thinking more than reaction and quick twitching, and the games we develop are supporting this approach.
We've been at this for coming up on 2 years now, and still going strong. Our core team is several dozen in number (quite big for an open source project). You may have seen our booth at the LinuxTag Expo last month. Our first release (of a primitive early prototype) was a year ago, and we're working up to our next release within a few more months (a simplified RTS game to demo our client and AI engine, first unveiled at LinuxTag). In a year or two, y'all are REALLY going to enjoy using what we're working on right now.:-)
Of course, everything is available under the GPL. This includes a considerable (and growing!) amount of art (including 3D animations), music, a fantasy game world called Dural, and a complete tabletop roleplaying game rules system. It is *easy* to get lost in our website looking at everything!
We try hard to be one of the easiest net projects to get involved with. We're strong believers in net projects as educational opportunities, so even if you've never done anything remotely like game development, but would like to have a cool project on which to develop your artistic, musical, writing, or C++/Perl/Python programming talents, I think you'll find WorldForge will suit your interests nicely. Really, the only requirements we have are to have an interest in making games, and persistance in sticking with it.
Because WorldForge advocates freedom in gaming, people only interested in making Big Bux won't fit in too well. Not that we have anything against money! But this is more of a hobby than a job, to us. (Good experience, though!)
WorldForge is like GNOME and GNU in that it is more of a collection of projects with a general overall goal to give uniform direction, than a single specific program being developed. We have a number of game projects, servers, clients, etc. underway now, but if you've got something that you're willing to develop as GPL'd software, we can make room for you.
How could the creativity of cheaters be harnessed in other ways, without ruining the game for non-cheaters? Maybe create games where you design in-game ships or weapons by writing some sort of psuedo-code ?
At WorldForge, we're doing exactly this. The client is made available in source code form so that the player can customize it to make it work better for them. And we make all of the server code available for download so players can look through it and discern new tricks for effective playing. If in doing so, they uncover a bug that can be taken advantage of to the detriment of other players, then they're welcome to make use of it - sometimes this is the best way to test out how bad the bug really is.
If I don't think the bug is worth my time fixing, then any players sufficiently bothered by it are welcome to download the source code to the server, find the area causing the problem, fix it, and submit a patch. If I disagree with their patch or otherwise refuse it, well then at the least they have the permission to establish a new server and compete with me. So I will probably work hard to make sure to include the patch!
So I guess a lot of stuff I see called cheats, I think really should be honestly called 'bugs', and responsibility placed with the programmers rather than the players. Some stuff - like denial of service or similar - that's just plain mean, and out of the server programmer's hands to prevent. But a lot of the in-game cheating is preventable via code.
Maybe I'm an idealist, but the best way to harness the creativity of cheaters, is, IMHO, to establish an environment where giving out fixes to cheats has as much glory as identifying the cheat in the first place.
We also strongly encourage (even urge) players to get involved in the game development process. Our present game server is written in Python, and we will encourage and allow extension of it by direct coding (the amount of extension is limited by the slowness of Python). Our next game server (being coded now - in C++), will allow players to design assemblies and mechanisms in-game, and automate them with scripting, among other things.:-)
And of course, since the client is open source, you're welcome (and encouraged) to automate your character as much as you want. (In my opinion, if the game is so simple that you *can* program a super-bot that wins consistently, then the game lacks adequate sophistication. AI programming is tough, and if allowing for this kind of "cheating" encourages lots of people to gain skill at it, then this makes the (game)world a more interesting place! Besides, programmers are cool and deserve an edge. *Wink*)
The problem with open source initiatives seems to with creativity, and this hurts in game developement the most.
There are plenty of creative people on the net. There are plenty of good coders on the net. The only trick is getting them to talk to one another. There are plenty of people who are good at getting people to talk to one another. I do not see how this task is impossible. It just takes some work.
Summary: I find it unlikely that an amazing open source game will emerge under the current community conditions.
I find the principle difficulty in making open source games is the public perception that it cannot be done. I don't understand why the open source philosophers have to make this mealy allowance. A secondary difficulty is that the open source development community is not providing the open source media creation tools necessary to creating games.
I have yet to see an open source project that is not a clone or a close relative of something that already exists in the world. Perhaps it's done better, but that's not the point.
Look harder. Often we pay more attention to the familiar than the unfamiliar when it comes to amature works - a time travel game may pass you buy, but you'll take note of the clone of Myth, since you already know and like it.
And also accept that many commercial games are nothing more than clones of previous games. In fact, how many of the great games out there are basically the same gameplay style, but with different graphics or a different rendering technology?
The answer to removing large pieces of junk from orbit is to send up a couple of tether-based OMVs to do it automatically.
Actually, most stuff under ~750 km altitude will decay all by themselves within 25 years or so, give or take a solar cycle. Even big stuff. Stuff above that altitude is going to be around there longer, but under 750 km altitude is where precious things like shuttle, station, and hubble lay, so that's where the most concern is.
NASA has recently imposed requirements that all satellites deorbit within 25 years, either coming back to earth, or being boosted up to above 1400 km (iirc).
Also, there are a LOT of satellites way, way out at GEO. But these are spaced so far apart that we generally merely boost them up to a slightly higher orbit and leave them there. There is no drag at GEO so no fear of seeing them run into other stuff.
On the positive side, the smaller an item is, the quicker it de-orbits due to atmospheric friction. For example, a cloud of dust (or sand) would de-orbit from LEO within a couple days. It's all about altitude.
Techically, it's a function of altitude, mass, and surface area. Solar cycles play a role as well; when we're in a solar max condition (lots of sunspot activity), the atmosphere "thickens" and thus spacecraft are subjected to stronger drag forces and will decay faster. Surface area is very important. At the end of life we'll feather a spacecraft's solar arrays to maximize atmospheric impingement, and thus go down faster.
OMV is not tether-based, btw. (I work with the guys that designed it, and they are always pulling out the little models and such. *Grin*) In any case, all you need is surface area, so if you wanted to do something fancy, consider just hooking on a big inflatable sail dohicky - cheap, low mass, and effective.
If you have the power to spare for a tether, I'd wonder if it wouldn't be simpler to just use electric propulsion; for a few hundred watts and a few tens of kilograms (and a year or two) you can deorbit most anything. Getting back up out of the drag well would be challenging if you wanted to reuse the orbit maneuvering craft. Probably better to just deorbit the whole mess. But if a spacecraft operator is on contract to deorbit a spacecraft, they generally like to get it done ASAP, and having to wait a few years for a slow deorbit can be expensive.
But the fact of the matter is that most of the garbage up there is *tiny* - bolt heads from old explosive bolt mechanisms, pieces of tape or foil, and bits of metal from explosions or impacts. Small teeny stuff.
Slashdot Mirror
Damn slashdot's tag filtering...
Shouldn't that be ?
Wouldn't it be more logical to put your donation into one of the open source game projects? I mean, that way even if the whole effort goes to the waste bin, at least you still get the source code...
Why does all open source software tend to have bad user interface?
Two reasons: First, because most folks *capable* of _creating_ a decent GUI are by definition competent enough to use the command line interface. Second, because people who are *that* dependant on the _graphical_ interface are too damn freaked by the commandline nature of compilers that they don't do anything about it.
Short answer: Either get used to the commandline or be friggin' brave enough to make the GUI better.
And for GOD sakes, some of the BEST software has ONLY a commandline interface, so NEVER equate commandline interfaces with commandline interfaces. Hmph!!!!!
*Very* well said. This is an excellent addressment of this issue. Frater, you should develop this into a full length essay, as it places the issue in its proper context. Failure of businesses is perpendicular to the issue of free software success.
The distributed server thing ala peer-2-peer for online playing is a great idea! Have each server be a land or portion of a land and you must pass through some kind of gate to move to the next server or perhaps cross some mountains, or take a boat ride, or enter some caves etc.
Yes, this is an idea that many have floated before, in various guises, over the years at WorldForge, and because of that I would have to bet that when we're further along, people will experiment with doing that. In fact, we're planning to put the hooks in to allow people to experiment with this into our next version of the server.
Now, there's a lot of issues to deal with in such a situation, but heck, that's what experimentation is all about, and it wouldn't be fun without some challenges, right? ;-)
It's impressive to see how quickly everyone is grokking what WF is about! And you know you're all welcome to come join in the fun with us, there's plenty of interesting work to go around.
Bryce Harrington ~ WF Coordinator fella
While it would be nice for people to have personal sattelites, the space junk would be horrible.
First of all, understand that the trajectories of every one of these is going to be calculated and tracked, so the chance of anything running into it during its lifetime will most assuredly be nil.
Second, these will be launched into a low earth orbit that has a relatively high rate of orbital decay due to atmospheric drag. Yes, there actually is a *little* bit of atmosphere at the height that these sats will be orbiting.
So, the worry about space junk is probably not warrented here. Yeah, these little contraptions will be "in the way" for a while, perhaps a dozen years, max, before they eventually re-enter the atmosphere and burn up.
The biggest worry with "space junk" is stuff that is at a higher altitude where it *won't* decay, or things that are untrackable (such as loose screws, bits of metal from explosive bolts, etc.)
What if there were a craft that could sweep the heavens? Would it use a free-electron laser to destroy the bulk of the craft? Would it be similar to a whale? A giant craft that takes in a region of space and filters out the crud from the vacuum?
Nice idea, but it's tons cheaper just to track what junk is already up there, and try to avoid creating more (or create it in orbits that will naturally decay with time). Besides, a craft able to maneuver and collide with such items would pose a risk of colliding with something and sending forth additional slivers of metal, paint flecks, and etc. Not to mention that it'd need tons of fuel in order to do all the required manuevering.
Why should games be any different? If the commercial developers won't make games, then we're going to have to do it ourselves, just like much of everything else in Linux.
As a blatant plug for my own project, this is exactly what we at WorldForge are shooting for. Good, free games targeted to Linux (with Windows ports being secondary.) If you want to see more Linux games, with the added benefit of being free and open, then lend a hand.
Bryce
Oh yeah? It is relatively simple to do something that has 3D, is networked and multiuser.. but if you are going to do something that is intended to be good and you want people to actually use the system you have a really big project on your hands...
Just from the top of my head: WorldForge, Metaverse, Verse etc.. Maybe it would be wiser to see how they are doing and choose to join on of them.
*Looks up*
Yup, WorldForge is quite far enough along to give a project such as this a major leg up, and we would be thrilled to collaborate with this project (or any project) working on virtual world types of things.
Even though us at worldforge don't speak of it a whole lot, I think we often give thought to how what we are doing could evolve into a virtual reality like system - distributed server clustering, in-game editing / building, player uploaded media, client-side scripting... All features that would be *critical* for a virtual reality-based system.
Anyway... so even though our goals are being thrust in a medieval direction, the architecture is generic and usable for a variety of things, and certainly should lend itself as a low level base for non-game applications too.
Times change, but not that much... I would have to suspect that there is still some urge to learn programming because of interest in games. And I definitely know that net projects are *still* one of the best ways to pick up new technology.
If this is in fact the case, then one of the best ways to promote education of free programming could be encouraging young folks to work on the various free game development projects out there. Fringe benefit: One day maybe getting more free, open source games that YOU can play. ;-)
And I'm not just spouting opinion here... I myself devote time to one of these game projects (www.worldforge.org), helping people learn about game programming, and I'm also participating in a project to author and promote free, open source textbooks (freebooks.myip.org).
If you have a few hours each week you can devote to helping one of these projects by helping teach or review people's code (or art!) and give good feedback, that would certainly be one of the best ways you can encourage learning of open tech. And if you need to learn some of this stuff your self and can afford a bit more time, well sheesh, do yourself a favor! ;-) And
in any case, participating in free communities is
a lot of fun, and can be very rewarding
personally. And of course it is the Right Thing
To Do. :-)
If anyone wants to leave questions about it here, I'll answer them later today, and pass them on to RMS.
Actually, I have a couple questions, although they're more philosophical than legal or technical. I'm running a project to create an online roleplaying game system, with source code under the GPL and all of the art, music, and game content released under the GPL and GFDL. The ideal we've chartered for ourself is the promotion and facilitation of Free Game Development, in the same spirit as the FSF promotes Free Software Development.
Yet it has come to our attention that guaranteeing the freedom of our source code will be difficult. On several occasions we have been approached by individuals wishing to make use of our code and media for commercial purposes, and have stated emphatically that they "cannot" release the contributions they would make (for the usual reason given - because they feel they couldn't make money otherwise). Now, the uncomfortable fact is that either through dynamic linking or through the "ASP loophole", they can run our server code with their additions and charge for access without ever releasing a line of their added code, as nothing legally or technically exists to prevent that.
But in discussing this with the other WorldForge developers I'm not so certain that there *should* be technical or legal preventions against this, for various reasons including one I'll outline in more detail below. The question I have been wondering and that I would like to get yours' and RMS' viewpoint on is whether or not we *should* be concerned about this? Since the GPL appears to allow keeping code secret either by not distributing the binaries, or by dynamically linking it, does this mean that it is morally okay to do so?
What I worry is that if it is possible for individuals to take advantage of our code and not have to share their own contributions back, it may stifle the free environment we are attempting to establish. I suspect that if sharing was required, then assuming all commercial participants follow this rule the competition would be fair. However if it is possible to hold parts of the game system proprietary, then it will be seen (rightly or wrongly) as a competitive advantage to do so, and thus in spite of all the problems we all KNOW are intrinsic in hiding source code, they will take this route instead.
Without the use of legal or technical means of ensuring the freedom, it would appear that we would need to fall back to reliance on "peer pressure" and tradition to ensure sharing of code. E.g., "blacklisting" companies that choose to use one of the loopholes.
Now, there is a side issue and a second question which is, I suppose, one of the issues peculiar to games. While with "normal" software there is usually little or no reason to prevent ALL of the code, documentation, and content from being released openly, with entertainment software it is sometimes desired to keep parts secret not for commercial reasons but instead to preserve some degree of mystery. One might argue that with a book, one is expected to read the pages in order and not cheat by reading the last page, however book reading is a solitary endeavor; this would be more akin to browsing through the poker deck when your partner is off buying beers. Now, there are many arguments and counterarguments on both sides that can be made. But here is the question: Does the need for hiding source code for purposes of ensuring mystery pose a legitimate exception to the free software / open source principles?
The approach we at WorldForge have been toying with is providing for "softcode" additions to the game, which are stored in a database and kept segregated from the primary game code, rather than encouraging use of the "ASP loophole" or dynamic linking loophole as workarounds. There are of course performance issues implied in using scripting rather than hard code, but we like this because it discourages hiding "too much" code.
Now, I hope our concerns are not dimissed because "it's just a frivolous game". Game software can and has been used for many purposes outside of entertainment, including education, visualization, and communication, and the issues outlined above will be of critical importance in assuring that these non-game applications of the software can enjoy the same freedom that the original code is being given.
The Freebooks Project was started a few weeks ago from an article here on Slashdot about Free/Open Source Physics (or other scholastic) Textbooks. The author of that article, Ben Crowell, proposed and helped start this project.
We decided that since our interests had more to do with the idea of writing free books than writing physics books, that we'd write a free book *on* writing free books.
Even though we've only had a few weeks, we've got many of the technical hurdles tackled and are getting down to collecting thoughts and ideas, brainstorming, and filling in the website. And if you're interested in lending your support to this cool (and critically needed) service to the open source and free software communities, check out the site, and join our mailing list.
When Galileo was built, NASA put a Big Huge Beefy antenna on there, that would deploy like a flower bloom, and provide Lotsa Data.
Now, this is a directional antenna - it puts out lots of data but only in a narrow cone. So they needed a backup antenna, for when the main one was not deployed or if it was not pointed right, just for basic communications (i.e., "Galileo, point main antenna towards earth"). So this antenna is omnidirectional but very small bandwidth (since you don't need bandwidth, after all.)
Yeah, the big one broke. So they have to use the dinky one for all the _data_ communication, too. :-P
This would be like your monitor burning out and having to figure out a way to use your PC speaker to do file management.
We would design a spacecraft, drawing it all up in 3D in CAD, then transmit the CATIA file over to the stereolith dept, who would process it over night to create the spacecraft.
There were some little drawbacks and quirks. The plastic is a bit flimsy, so in order to have arms (such as the ones that deploy the solar array wings) someone needs to edit the 3D CAD file to remove those bits, and after the model is created, to put metal wires in and glue things together.
In fact, in the hands of a good plastic model builder with a few week's time, some pretty incredible results can be achieved. One spacecraft we designed had a really tricky maneuver and deployment sequence, and our model maker took time to put in the rotational mechanics so that we could use the model to play around with how this would work. (Sometimes when you can play with a real toy you can figure stuff out in a LOT less time than if it was only in your head or a whiteboard.)
First, the sheer size of the thing... There have been few (if any) spacecraft propulsion systems this big and this powerful put up into space.
Second is human safety. Take a look at the rendering and you'll see an access port running down between the two "ears". The shuttle docks there and the astronauts traverse it. Obviously, there are concerns about contaminates getting in there... There were questions about whether to pressurize this corridor or not - if it has to hold a pressurized environment, then it would end up being MUCH more expensive than if it wasn't. On the other hand, having to suit up to go from the station to the shuttle is a hassle and introduces other kinds of risk.
Third was refuelability. We considered whether to have a system that could be refilled on orbit, versus one where one entire 'ear' is pulled off and brought back to earth for refurbishment. Obviously, there are pros and cons each way. One interesting issue is fluid depletion: If there was a problem with the system, you may need to vent out the tank contents before being able to refill it or take it home - so we have to be careful that whatever chemicals are ejected won't corrode or contaminate anything. It looks like they decided to go with a hydrazine monoprop system, which is very safe, but has less performance than other options, and thus will require more trips by the shuttle.
It's interesting and a bit disappointing that NASA has chosen to stick with Boeing even after they failed so badly with the first design. Could have been a great opportunity for some other companies to get into the human rated spacecraft market. Ah well...
I hate to call this bogus, but the article's author is clearly clueless about chemistry, and is implying things that just can't be. I used to size tanks for storing various fluids and gases, including Nitrogen. Yes, it is true that you can get useful work out of pressurized nitrogen. But the *amount* of work is rather miniscule. We sometimes used pressurized nitrogen as a rocket propellant, but only because it was such a safe, predictable fuel; the performance was a tenth of what you could get with conventional chemical rockets (even rockets burning gasoline.) The article draws a comparison with batteries. With batteries, they may not hold a lot of energy, but you can recharge them. With gas, the depressurization process is essentially on-way. Getting energy back into a nitrogen pressure vessel is just too hard. Of course, then there's the danger...
An interplanetary mission will run for on the order of hundreds of millions (or less, during the Faster/Cheapter/Better bargain days.) On the other hand, Shuttle/ISS/Moon manned endeavors run out into the tens of billions of dollars. Look at the cost of a single shuttle mission. Ow.
NASA is obsessed with shooting big, dumb rockets at long distance targets at hugh cost.
There's a reason why they use expendable launch vehicles: Launching a spacecraft on the shuttle is just too dang expensive. Not just because the Shuttle is an expensive launch vehicle (it is), but because anything that is launched must be checked umteen ways to Saturn to make sure it's TOTALLY SAFE. Anything that risks astronauts' lives - even in the slightest - is a major, major no-no. Lower risk equals higher cost, of course.
So in fact, in terms of return-on-investment, the missions to far flung places are really a small drop in the bucket compared with anything that has to do with the shuttle. And using the "big dumb boosters" (dumb?) really is the most cost efficient, reliable way to go (at least for now).
Well, but it proves the model, and that is a very important thing. Success breeds success, and with King successful, other writers are going to give it a shot. Yeah, other authors won't have the ready fame to leverage, but they know this, and that makes them realize that they might need to be a bit more creative in how they achieve their aim. King has done the good deed of nailing down the high end. Expect that others are going to be exploring the lower ends. I betcha we see a bunch of different models brought forth over the next year or two. I'm sure people will find the best one.
Pluto/Kuiper Express (PKE) was to be one of three JPL solar system exploration missions. The other two include Europa Orbiter (intended to determine the existance of a subsurface ocean), and Solar Probe (intended to determine the origin of the solar wind). PKE's purpose was to image Pluto and Charon (Pluto's moon) and a Kuiper Belt object. EO's biggest challenge is it's complex orbit insertion. SP, of course, has to deal with an intense thermal environment.
PKE's principle challenge was to reliably conduct an autonomous encounter navigation after spending 8 years travelling out there. The craft would be zipping past Pluto at a good clip, and clicking a few pictures (for later transfer back to earth) would be tricky - gotta have the camera pointed in just the right directions at just the right time.
The reason autonomy is necessary, is that at Pluto, the round-trip time for a beam of light to travel between Pluto and ground control is 8 hours, but the entire Pluto encounter only lasts a few hours.
Another problem, mentioned in the article, is that finding a launch vehicle with sufficient performance to get enough mass (a few hundred kg's) going on an accurate trajectory, is pretty tricky.
I think it'd be a pretty cool mission, although I can understand why NASA may prefer to direct their funds towards other projects that would return larger amounts of results for less risk. I hope this doesn't mean Europa Orbiter or Solar Probe are also in danger of cancellation.
There is already a scary glut of launch vehicles today. The manufacturers had been forcasting a lot of demand, based on the expected success of Iridium. Iridium is a constellation system, which requires lots and lots of launches, as compared with single-launch satellites like the ones the Sea Launch puts up.
So... When Iridium went bankrupt, we saw an immediate evaporation of interest in constellation systems. Very simply, investors don't want to take the risk. Sometimes the systems have been reformed as non-constellation systems, or lumped onto other satellites, and other times they're simply cancelled. In any case, the net result is the same: The projected large market for launches is vanishing rapidly.
I think all of us know that the way to get low per-widget costs is to make a lot of them. Henry Ford proved this out with his affordable mass produced cars. And we all know that when you write a piece of software, the more customers you can sell to, the wider you can spread your development costs, and the lower a price you can charge and still make profit. Competition is a great way to drive costs down, but doing it in volume is an even better way.
So I don't know, maybe there will be a "clearance sale" or some such, but I *think* the result ain't going to be what we'd like. Having more launchers is fine, but what we *really* need are a lot more launches. Nothing else is really going to drive costs down to where we need them, IMHO.
Good question. The basic answer is that the speed of programming in Python isn't as valuable to us for this particular application. The stuff that isn't performance critical also happens to be the simpler bits of the program, so even if it is a bit harder to do in C++ than in Python, it doesn't matter all that much in the grand scheme. Plus, having the entire core written in one language is nice for simplification and elimination of interfaces (and the overhead).
What we'll probably end up with is the server's core in C++, and pluggable modules that can be written in Python or whatnot to implement some of the game-specific stuff. That way, the C++ will be limited to the areas that maintainers and future game developers won't be getting into very often.
WorldForge's core technology is being developed to be game-generic. Present plans include multiplayer RPG and RTS games. We've nothing against violence in video games, but in most of the games we have planned right now it plays a lesser role than in commercial games. We value problem solving and thinking more than reaction and quick twitching, and the games we develop are supporting this approach.
We've been at this for coming up on 2 years now, and still going strong. Our core team is several dozen in number (quite big for an open source project). You may have seen our booth at the LinuxTag Expo last month. Our first release (of a primitive early prototype) was a year ago, and we're working up to our next release within a few more months (a simplified RTS game to demo our client and AI engine, first unveiled at LinuxTag). In a year or two, y'all are REALLY going to enjoy using what we're working on right now. :-)
Of course, everything is available under the GPL. This includes a considerable (and growing!) amount of art (including 3D animations), music, a fantasy game world called Dural, and a complete tabletop roleplaying game rules system. It is *easy* to get lost in our website looking at everything!
We try hard to be one of the easiest net projects to get involved with. We're strong believers in net projects as educational opportunities, so even if you've never done anything remotely like game development, but would like to have a cool project on which to develop your artistic, musical, writing, or C++/Perl/Python programming talents, I think you'll find WorldForge will suit your interests nicely. Really, the only requirements we have are to have an interest in making games, and persistance in sticking with it.
Because WorldForge advocates freedom in gaming, people only interested in making Big Bux won't fit in too well. Not that we have anything against money! But this is more of a hobby than a job, to us. (Good experience, though!)
WorldForge is like GNOME and GNU in that it is more of a collection of projects with a general overall goal to give uniform direction, than a single specific program being developed. We have a number of game projects, servers, clients, etc. underway now, but if you've got something that you're willing to develop as GPL'd software, we can make room for you.
At WorldForge, we're doing exactly this. The client is made available in source code form so that the player can customize it to make it work better for them. And we make all of the server code available for download so players can look through it and discern new tricks for effective playing. If in doing so, they uncover a bug that can be taken advantage of to the detriment of other players, then they're welcome to make use of it - sometimes this is the best way to test out how bad the bug really is.
If I don't think the bug is worth my time fixing, then any players sufficiently bothered by it are welcome to download the source code to the server, find the area causing the problem, fix it, and submit a patch. If I disagree with their patch or otherwise refuse it, well then at the least they have the permission to establish a new server and compete with me. So I will probably work hard to make sure to include the patch!
So I guess a lot of stuff I see called cheats, I think really should be honestly called 'bugs', and responsibility placed with the programmers rather than the players. Some stuff - like denial of service or similar - that's just plain mean, and out of the server programmer's hands to prevent. But a lot of the in-game cheating is preventable via code.
Maybe I'm an idealist, but the best way to harness the creativity of cheaters, is, IMHO, to establish an environment where giving out fixes to cheats has as much glory as identifying the cheat in the first place.
We also strongly encourage (even urge) players to get involved in the game development process. Our present game server is written in Python, and we will encourage and allow extension of it by direct coding (the amount of extension is limited by the slowness of Python). Our next game server (being coded now - in C++), will allow players to design assemblies and mechanisms in-game, and automate them with scripting, among other things. :-)
And of course, since the client is open source, you're welcome (and encouraged) to automate your character as much as you want. (In my opinion, if the game is so simple that you *can* program a super-bot that wins consistently, then the game lacks adequate sophistication. AI programming is tough, and if allowing for this kind of "cheating" encourages lots of people to gain skill at it, then this makes the (game)world a more interesting place! Besides, programmers are cool and deserve an edge. *Wink*)
Bryce
Top Geek at WorldForge
There are plenty of creative people on the net. There are plenty of good coders on the net. The only trick is getting them to talk to one another. There are plenty of people who are good at getting people to talk to one another. I do not see how this task is impossible. It just takes some work.
Summary: I find it unlikely that an amazing open source game will emerge under the current community conditions.
I find the principle difficulty in making open source games is the public perception that it cannot be done. I don't understand why the open source philosophers have to make this mealy allowance. A secondary difficulty is that the open source development community is not providing the open source media creation tools necessary to creating games.
I have yet to see an open source project that is not a clone or a close relative of something that already exists in the world. Perhaps it's done better, but that's not the point.
Look harder. Often we pay more attention to the familiar than the unfamiliar when it comes to amature works - a time travel game may pass you buy, but you'll take note of the clone of Myth, since you already know and like it.
And also accept that many commercial games are nothing more than clones of previous games. In fact, how many of the great games out there are basically the same gameplay style, but with different graphics or a different rendering technology?
Actually, most stuff under ~750 km altitude will decay all by themselves within 25 years or so, give or take a solar cycle. Even big stuff. Stuff above that altitude is going to be around there longer, but under 750 km altitude is where precious things like shuttle, station, and hubble lay, so that's where the most concern is.
NASA has recently imposed requirements that all satellites deorbit within 25 years, either coming back to earth, or being boosted up to above 1400 km (iirc).
Also, there are a LOT of satellites way, way out at GEO. But these are spaced so far apart that we generally merely boost them up to a slightly higher orbit and leave them there. There is no drag at GEO so no fear of seeing them run into other stuff.
On the positive side, the smaller an item is, the quicker it de-orbits due to atmospheric friction. For example, a cloud of dust (or sand) would de-orbit from LEO within a couple days. It's all about altitude.
Techically, it's a function of altitude, mass, and surface area. Solar cycles play a role as well; when we're in a solar max condition (lots of sunspot activity), the atmosphere "thickens" and thus spacecraft are subjected to stronger drag forces and will decay faster. Surface area is very important. At the end of life we'll feather a spacecraft's solar arrays to maximize atmospheric impingement, and thus go down faster.
OMV is not tether-based, btw. (I work with the guys that designed it, and they are always pulling out the little models and such. *Grin*) In any case, all you need is surface area, so if you wanted to do something fancy, consider just hooking on a big inflatable sail dohicky - cheap, low mass, and effective.
If you have the power to spare for a tether, I'd wonder if it wouldn't be simpler to just use electric propulsion; for a few hundred watts and a few tens of kilograms (and a year or two) you can deorbit most anything. Getting back up out of the drag well would be challenging if you wanted to reuse the orbit maneuvering craft. Probably better to just deorbit the whole mess. But if a spacecraft operator is on contract to deorbit a spacecraft, they generally like to get it done ASAP, and having to wait a few years for a slow deorbit can be expensive.
But the fact of the matter is that most of the garbage up there is *tiny* - bolt heads from old explosive bolt mechanisms, pieces of tape or foil, and bits of metal from explosions or impacts. Small teeny stuff.