Raven's Chris Foster updated his .plan with some clarifications about how gameplay will unfold in Raven's upcoming Quake III-engine Star Trek Voyager game, mentioning that even more detail on this stuff can be found in Mike Gummelt's .plan:

Ah, the joys of less than perfect communication!

In order to clear up a few items regarding our game, I felt it was necessary to update my .plan file today.

First off...you play the Game as Alexander Munro, a security specialist aboard the Voyager. A member of an elite force of away team operatives, Munro will be called upon to defend the ship and its crew from the dangers in a hostile environment. Trapped in an artificial pocket of space by alien beings, Voyager is disabled and beset on all sides by ruthless scavengers as well as the race which has them trapped.

He will explore many areas on Voyager, (yes even the mess hall...), as well as numerous alien craft also trapped within the pocket.

The game will be a single-player affair, with Holomatch options; including Deathmatch, other team games and possibly Multiplayer Co-operative missions outside of the regular single-player game.

Munro will have a number of weapons at his disposal throughout the game, some Federation tech... some not.

Holomatch will basically be a Holodeck generated combat stage with the ability to fight other players and score as if running a training exercise. When a player is 'killed' he is transported back to the command staging area to reset himself, re-arm and then 're-spawn' (i.e. randomly be transported back within the playing area).

As an aside, what do you all think about the idea of 'Siege' type missions for Holomatch?

Hope this answers most of the questions I got.

And No, you are not going to be able to play as Tuvok in the game, sorry! Possibly in Multiplayer, but not in the single-player game.

Also...for a more concise definition of the Hazard Team (the 'elite force' mentioned earlier) as well as a synopsis of the characters, see Mike Gummelt's .plan file!

Also, Raven's Jake Simpson updated his .plan mentioning an interview with him on GameDev.net, and more on his unsolicited (and apparently un-agreed with) opinion about the value of publishing Carmack's worklog, along with some accounts of his own work, which I'm going to risk the possible disinterest of other programmers by quoting here, since it covers some interesting stuff about LOD support in Star Trek Voyager game as well as a bit about eye-candy in Soldier of Fortune:

So it looks like the LOD stuff I looked into may not be going into Star Trek. The reasoning here involved low poly count models. Traditionally, Raven has been extremely good at producing attractive low poly count models. This has come after years of experience that our modeler have had, plus large amounts of beatings until they get it right :) However, one of the things that LOD is traditionally NOT good at is reducing low poly count models even further and making them look ok. Yes, it is understood that they are reduced in size, so you don't notice this so much, but still, there comes a quality issue and at some point, modelers and designers need to say "enough". Really and truly, to do LOD so it looks correct, you should be building high poly count models to begin with. Since we already have a decent amount of work done on the models and animation for Voyager, there comes a point where the amount of time to redo it all is not balanced by rebuilding everything and pushing our delivery date back. We are still investigating the whole dynamic LOD approach, and are still undecided on its final form for Star Trek right now. As my father would have said, if we have the time to invest in code experiementation in an ongoing project, then we'll suck it and see.:)

I'm doing some eye candy for SOF right now. Its really cool to be free enough to have the time to experiement with fluff stuff to try and get it right. Since I'm a free resource right now, they are applying me to stuff that otherwise may not have been so addressed. It looks like I'll have my hands in the effect scaling code too, which is fine by me :) Nathan Albury has added a very cool Special Effects generating tool into the game code base, something we've all been talking about for while. This takes effect generation out of the coders hands, (thankfully, since it takes longer for a coder to do it than an artist) and places it in the designer hands. I know I'm happy about this :) Doesn't stop me making effects but it sure does allow everyone a fair crack at it now :)