Tremulous Forum
General => General Discussion => Topic started by: Urcscumug on March 20, 2009, 09:22:40 am
-
http://code.google.com/soc/
As I understand it, Google pays money to both the "mentoring organization", which can be an individual as well, and the students who choose to work on the project. See the FAQ linked from the above page for lots more details.
Wouldn't it be a good idea for Trem to try to enter GSoC 2009? It would generate some publicity and there's bound to be some work that can be done around the engine or whatever and is need of manpower. If the pitch is interesting enough I think students might be interested, both for working on a game and it being a game which is quite out of the ordinary.
-
Too late for that.
-
Oh, I haven't noticed mentor applications ended on the 18th. :)
Anyway, for the sake of my curiosity, are there parts of Trem that would benefit from such an endeavour? What would you (Amanieu or others) pick to let a bunch of hungry students chew on? Because there's always next year.
-
I would go for a physics engine (rolling barrels, rolling balls, pushing objects around, etc). Also a better hit-test system (based on model bones).
-
What about dynamic lighting? I was under the impression that Trem doesn't have it (or, if it does, it's just not very obvious). I would imagine for instance that weapon fire should light its surroundings, but it doesn't happen. All we see is the "fixed" lighting defined in the map. No shadows either.
Obviously, this falls under the "pure eye-candy" category. I definitely understand why physics would rate higher priority.
-
What about dynamic lighting? I was under the impression that Trem doesn't have it (or, if it does, it's just not very obvious). I would imagine for instance that weapon fire should light its surroundings, but it doesn't happen. All we see is the "fixed" lighting defined in the map. No shadows either.
Obviously, this falls under the "pure eye-candy" category. I definitely understand why physics would rate higher priority.
What adds more to a map? A gimmicey bridge, or a swinging light (shit, can't have the second without physics : P)? I say the light. Physics are nice, and fun, but they can change the entire gameplay, for better or for worse.
But, oh yes, physics would be nice. At least ragdolls. And, of course, with physics comes breakables! (Must have smashable windows to make my map concept work. And dynamic lighting, actually. D:)
-
I realized the error I've made with the previous post soon after: please, let's not turn this thread into another debate over physics vs graphics.
Returning on topic: IMHO it would be time better spent to dedicate this thread to planning a possible participation of Trem in future GSoC editions. I've changed the thread title accordingly (took 2009 out).
A starting point would be this: Google's organization selection criteria (http://socghop.appspot.com/document/show/program/google/gsoc2009/orgcriteria).
A first useful step would thus be the above: coming to terms with how you'd use a bunch of students unleashed on the Trem code, given the opportunity.
The second would be be putting together a succint list of selling points for Trem, from a dev perspective, things that would make Google accept it in GSoC.
The third step would be how you'd go about introducing a student (or any person with the required coding skills) to coding for Trem. How can they tell if they got the skills? What are the requirements? What development environment do they need? What previous experience? etc.
All developers, past and present, who would like to throw their 2c in, please do.
This brainstorm would also benefit another topic. I'd like to take some time at some point in the future and give some real loving to the official Trem wiki. The development section will, naturally, need it too. Whether Trem will try to go for GSoC 2010 or not, we can still gather useful guidelines for would-be contributors and populate the wiki. It can't hurt.
-
More importantly, you need to find a trem-dev with all the necessary time.
-
What about dynamic lighting? I was under the impression that Trem doesn't have it (or, if it does, it's just not very obvious). I would imagine for instance that weapon fire should light its surroundings, but it doesn't happen. All we see is the "fixed" lighting defined in the map. No shadows either.
Obviously, this falls under the "pure eye-candy" category. I definitely understand why physics would rate higher priority.
Open console, type /cg_shadows 2 or /cg_shadows 3 and you will have shadows. Dynamic lighting is also implemented, but it's based only on the distance between the light source and the lighted surface, no shadow effects etc.
-
Q3 stencil shadows are unclipped, hence the feature is abused to see the location of trappers and players behind doors and detail walls, etc.
"True" dynamic lighting such as Doom3 is rather slow in the open source world - see XreaL, Darkplaces, though DP still uses lightmaps. If this is the direction the community wishes to go in then I vote for waiting for the Id tech 4 source to be released. Lightmapping with per-pixel effects (see Sauerbraten et al) can also be put to good use. Both will require much work on the game assets - normal/bump/gloss/whatever maps for each texture. Any asset migration from a lightmapped engine without per-pixel lighting to a modern engine is a huge task.
-
Q3 stencil shadows are unclipped, hence the feature is abused to see the location of trappers and players behind doors and detail walls, etc.
"True" dynamic lighting such as Doom3 is rather slow in the open source world - see XreaL, Darkplaces, though DP still uses lightmaps. If this is the direction the community wishes to go in then I vote for waiting for the Id tech 4 source to be released. Lightmapping with per-pixel effects (see Sauerbraten et al) can also be put to good use. Both will require much work on the game assets - normal/bump/gloss/whatever maps for each texture. Any asset migration from a lightmapped engine without per-pixel lighting to a modern engine is a huge task.
xreal uses lightmaps again (for hdr, they were what broke compatibility with q3bsp)
What about dynamic lighting? I was under the impression that Trem doesn't have it (or, if it does, it's just not very obvious). I would imagine for instance that weapon fire should light its surroundings, but it doesn't happen. All we see is the "fixed" lighting defined in the map. No shadows either.
Obviously, this falls under the "pure eye-candy" category. I definitely understand why physics would rate higher priority.
What adds more to a map? A gimmicey bridge, or a swinging light (shit, can't have the second without physics : P)? I say the light. Physics are nice, and fun, but they can change the entire gameplay, for better or for worse.
But, oh yes, physics would be nice. At least ragdolls. And, of course, with physics comes breakables! (Must have smashable windows to make my map concept work. And dynamic lighting, actually. D:)
take a look at the alien base in karith.
-
take a look at the alien base in karith.
Aww, I was gunna say that.
-
I debated entering trem into GSOC (last year too) but it comes down to the fact that we simply don't have any developers who have the significant amount of spare time to be a proper mentor. We all have very busy lives and Tremulous development is not currently on pace with what a successful GSOC organization would need. Probably next year though I will definitely make an effort.
Khalsa