|
Pages: [1] 2 3 ... 5
|
 |
|
Author
|
Topic: The road goes ever on: The Road to 0.4, #1 (Read 15699 times)
|
Michael Martin
Core Team
*Smell* controller
 Offline
Posts: 387
|
Hello, Forumites.
Given the rather lengthy timespans between releases (even unofficial ones), I hereby inaugurate a "The Road to 0.4" feature. I'll be posting occasionally (right now I'm envisioning every 2 weeks or so, but that may be too frequent given that classes have started for everyone) the progress and plans we have for 0.4.
This is more than just a link to the ChangeLog (though that will tell what what's *currently* been finished, of course) -- it's more of a look at the changes we're planning.
I classify changes as being either "visible" or "invisible." A "visible" change is one where the end user's experience has changed somehow; new features, shinier graphics, different menu options, etc. "Invisible" changes are changes in the way the program or data are structured - relevant to people making mods of the program (or porting it to new backends, or whatever).
But this is the first one, so a quick Changelog summary is in order. There have been a dozen or so bug/glitch fixes, but I'm not going to focus on those here; the ChangeLog (or Bugzilla) handles those better. We've made two visible changes, and two major "invisible" ones.
First, and most important: We have some basic video support. fOSSiL managed to reverse engineer the video player the 3DO Star Control 2 used, and if you have the disc and a 3do disc extractor, you can now play the in-game movies (at least, the intro and ending ones. "Ship spins" still aren't implemented.) We can't distribute the videos because (a) they're frickin' HUGE, and (b) we don't have permission (TFB didn't control the rights to them, so they couldn't grant them to us).
Also, we had an enhancement contribution from chmmravatar that remembers which saveslot you last used and defaults to that if you save again. Currently this only lasts during your playsession, but it can come in handy if you're using slot #37, say.
We've had two major invisible-to-the-end-user changes that should make developing UQM easier. In the first change, I took a massive hatchet to the threading and synchronization systems. My first shot at this wasn't terribly well received by the rest of the core team, and on further discussion, we came to the conclusion that nearly all of the original synchronization code wasn't really proper. I don't really want to get into the full technical details here (I'm writing a developer doc about the final system we're using, which will be added to CVS at some point soon), but there are various cross-thread synchronization constructs that you need to keep the program from tripping over its own feet; while, in theory, all of them are equivalent, there's usually one that's preferable for whatever you're trying to do (more efficient, easier to program correctly, or both) so most of them are offered by SDL. We swept through the code and changed most of the code's synchronization so that it always did it in the simplest way. (While we were at it, we got rid of some spurious errors and ensured that it was possible to get reasonable error messages always.)
Second, for all releases so far, the subtitle-drawing code and the music-track playing code have been inextricably tied together. fOSSiL has begun splitting them apart and making them separate systems.
Okay, so that's what's been done. Here's what we're looking at in the road ahead...
Visible stuff first.
- That "Setup" menu option really needs to do something. Some efforts have been made (with the UQM launcher utilities) to get around the fact that the only way to configure UQM right now is to pass it boatloads of commandline options. A few (-n springs to mind, and it may yet come to pass that -o and -r will have to do that too) will need to stay there. The others, however, should be mutable at run time, via Setup.
- Setup should also allow for online key/joystick configuration. I'm still not sure how fine-grained the control of this should be. (0.3's granularity is ludicrously fine, moreso than most players, I think, would really want. In-game shortcuts for "up is THIS, down is THIS, etc.," should probably be part of the interface.)
- The current way content packs work is that you stick the addons into a directory and activate them from the command line. If they interfere with one another, which resource is loaded is resolved to precedence rules. We have as an eventual goal the ability to have fine-grained control over this. For example, one could say "Use the 3DO soundtrack for everything, but use the PC orbital music, and play the remixed version of the QuasiSpace theme." This might even go to the extreme of allowing the specification of arbitrary files for the various songs.
Invisible changes:
- We envision using XML documents as a universal format for most of the non-binary data, and using this to replace the many ad-hoc file formats that scattered throughout the content. If nothing else, the resource locator code (replacing .ani and .ndx, at least) will be XML-based.
- Multiple decoders should be made available, and new ones should be easy to add. This way if someone makes their own videos, say, they can tell UQM to invoke (say) the AVI-playing libraries.
- Once you get past the basics of reading the keyboard or joystick and mapping that onto actions like "thrust" and "fire", there are no fewer than five input cores in UQM's game logic. Refactoring this into a single, Grand Unified Input Scheme would be nice, and would also allow configuration of things like the key-repeat rate.
- There are various places where behavior and/or data are hardcoded that don't, technically, have to be. (Ship statistics, star data, etc.) Data could, conceivably, be extracted into separate documents (again, we're pretty sure we want to use XML for all this, parsers are widespread, reasonably fast, and will be viable over the long term), and behavior could be specified with dynamically linked libraries (this is a bit more pie-in-the-sky, and would require quite a bit more work to make portable). If you have some modifications that you're itching to do, and you don't see any invisible changes pertaining to the change, study the UQM source and see how difficult it would be to add. If it would be easy if only the program did this instead of that, consider documenting that chunk of code, and contributing that documentation along with the enhancement proposal. This doesn't guarantee that we'll make the changes that make that enhancement easy; it definitely doesn't mean we'll make the enhancement ourselves (but then, the postulate here was that you wanted to do it
 ) but it's certainly more likely to be considered, and we'd always appreciate it if people go through the original code to figure out what the heck it actually does.
So, that's the grand roadmap to 0.4 and beyond. We aren't actively working on all of this -- summer has ended for us, and a lot of the Grand Visions depend on the first steps of them working out the way we foresee -- but that's the way things go.
It's also one of the reasons we don't set ourselves deadlines.
|
|
|
|
« Last Edit: September 28, 2003, 09:28:33 pm by mcmartin »
|
Logged
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Spurk
*Many bubbles*
Offline
Posts: 115
|
I'm curious on your last invisible change, Mr. Martin. Are you saying you'd like to extend the system so that people can make arbitrary plugins? Are you hoping to allow people to do everything from replacing the music to creating a new race/ship to allowing people to browse webpages from within UQM? (I'd count that last one as silly, but then again I have a number of programs with browser plugins that really don't need it.)
|
|
|
|
|
Logged
|
|
|
|
guesst
Enlightened
Offline
Gender: 
Posts: 692
Ancient Shofixti Warrior
|
Wow.
Just wow.
The slideshow for the non-3do intro/extro wasn't mentioned however. Any chance of getting that in?
|
|
|
|
|
Logged
|
|
|
|
Michael Martin
Core Team
*Smell* controller
Offline
Posts: 387
|
What I can tell, it's very near 1.0 when 0.4 is finished. Once all the features are in, it leaves alpha and becomes beta. This is where stability and portability become the primary goals. Once we've gotten it running everywhere we want, acceptably (at minimum, Windows, Linux, OS X, and the BSDs, under 32- and 64-bit architectures), and left it in beta for awhile to make sure that it's doing its thing properly, then we announce 1.0.
0.4 will be, if not the first beta release, then a very late alpha release, quite possibly the last.
The slideshow for the non-3do intro/extro wasn't mentioned however. Any chance of getting that in? To my knowledge, nobody's volunteered to set that up yet. A decision has been made to delay that until we write the XML-based resource locator, so that we don't have to put it in, take it out, and put it back in again. The actual slides themselves are sitting in the content directory.
Yeah, it'll be there by the time it reaches beta. If a contributor gets excited about it and writes code for it before 0.4, then it'll be there, too.
I'm curious on your last invisible change, Mr. Martin. Are you saying you'd like to extend the system so that people can make arbitrary plugins? Are you hoping to allow people to do everything from replacing the music to creating a new race/ship to allowing people to browse webpages from within UQM? (I'd count that last one as silly, but then again I have a number of programs with browser plugins that really don't need it.)
Maybe not arbitrary. But some flexibility would be nice. "Can we add our own ships" is probably the second most requested enhancement after netplay. The way the ship code works, the old .SHP files were effectively dynamically linked libraries in their own right. UQM just links all of them into the executable. So doing "new ship files" would really have to boil down to plugins. Making it so that changing the Earth Cruiser's top speed were a simple matter of editing a text file, however, would be a lot simpler to add.
Enabling new shifts would require a major architectural shift from what we have now, though, so there's no guarantees that we would put such a thing into 1.0. There's also the issue that there's nothing stopping somebody from making your "special weapon" be "try to email your password file to me." The only real defense against that is that, since UQM was licensed to us under GPL, any ship plugins that were actually distributed would also have to be under GPL as well, and you'd be able to check the ships' logic for trojans before using them.
The extensibility point extends beyond 0.4, and into, basically, "as long as we're rewriting all the resource stuff, we might as well make things extensible when it's reasonably painless to do so." Off the top of my head, the starmap, the coarse parameters of the starships, and the nature of the communication animations all are things that could be turned from enormous struct initializers (which they are now) into data files that could be read in later. We would like to avoid wholesale rewriting of the core game logic for 1.0; it's what we've playing this past decade, so we don't really have to worry if we're "getting it right." We haven't seriously discussed how to organize development once beta status is reached and forks really become feasible; we'll probably have that discussion once we get closer to it.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
|
|
|
|
guesst
Enlightened
Offline
Gender:
Posts: 692
Ancient Shofixti Warrior
|
[Will intro/extro slideshows be made?]
0.4 will be, if not the first beta release, then a very late alpha release, quite possibly the last.
To my knowledge, nobody's volunteered to set that up yet.... The actual slides themselves are sitting in the content directory.
Yeah, it'll be there by the time it reaches beta. If a contributor gets excited about it and writes code for it before 0.4, then it'll be there, too.
Come on contributors!
[What kind of mods can there be]
Maybe not arbitrary. But some flexibility would be nice. "Can we add our own ships" is probably the second most requested enhancement after netplay. The way the ship code works, the old .SHP files were effectively dynamically linked libraries in their own right. UQM just links all of them into the executable. So doing "new ship files" would really have to boil down to plugins. Making it so that changing the Earth Cruiser's top speed were a simple matter of editing a text file, however, would be a lot simpler to add.
Enabling new shifts would require a major architectural shift from what we have now, though, so there's no guarantees that we would put such a thing into 1.0. There's also the issue that there's nothing stopping somebody from making your "special weapon" be "try to email your password file to me." The only real defense against that is that, since UQM was licensed to us under GPL, any ship plugins that were actually distributed would also have to be under GPL as well, and you'd be able to check the ships' logic for trojans before using them.
Hmm, that would be an annoying thing for someone to do with this little project. Then again, if it happens you could get some free publicity ... on the news. Yeah, that might be bad, but bad publicity is publicity.
Would it be possible for someone to make a mod that would change the nature of the game beyond adding ships? Something like making a new sc1-stragety type game using UQM's code as a jumping off point? Just a thought. Also, what about updated graphics and increased turning slices?
|
|
|
|
|
Logged
|
|
|
|
Chrispy
Enlightened
Offline
Gender:
Posts: 917
Vlik Dweller
|
if u want a project that will take a lot of time, try putting in it a bigger screen resolution, and giving it mordern standerd graphics. id love to c that, but im not going to help make it. im just asking for it.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2 3 ... 5
|
|
|
|
|
Deep Jiffa Owns j00!
