Work done, to be done, planned

#1 My main efforts:

1) movingInteriors

Presently this is on hold, adding doors seems to be the first thing on the list. I'll be adding a TCP Core project for this soon (with myself as organiser).

2) breakable Interiors

Part of the above work.

3) Alternate render methods for player character (cel shading etc)

I'll also try and organise this effort, as its not just cel shading, but also getting to grips with the renderer side of the engine a bit more (doing some groundwork towards a later project on shaders).

Phil.

#2 i'm thinking of working on the q2 engine ,till torque gets more advanced, since im not that skilled in engine coding as others try to explain it,i wanna do single player,and to me it looks as torque is a ways off for that.

[added]
after thinking on it for a few day there are two things , that are realing holding me up ,,,one and most important is monster ai, this is somthing i am going to have to do myself, i looked at the ai code that is already started in torque and it looks as if its for bot (im not doing bots in my game) im doing monsters, ecah with its specific personality if you will ,

the second thing is avi or infact i may do a popup question and answer type gui, but definately avi for handeling speacial events that need to occure

{added 9-23-2)
hehe this is old,frank b. took care of the ai pathing :) thanks, made me take the weekend off from " homestead work" to play with torque again.

#3 Gary, the "single player" of torque is exactly what you get with the single player of Q2. Its a loopback connection. There really is almost no difference between the two models (single player and multiplayer).

I'm working on a single player game myself.

Phil.

#4 Stuff I'd like to finish:

-AI Pathfinding...sigh. I put this off so much. I think my current plan will actually work once I finish it.

-AI Objects. Objects that are AI controled, that don't need as much flexibility as the AIPlayer. Basically an AI controled object that doesn't take up a player slot.

-Shader Layer. Everyone talks a lot about doing shaders, but when it gets down to it, it's a pain in the ass. Sure they're great, but you have to write them twice and check which kind of GL call you need to make. This would be a royal pain. It's my opinion that it'd be easier to take GL/ATI like calls, then turn them into nVidia assembly and run nvparse on it. I haven't thought too much about it, primarly because I don't really want to do it, I just want it done. (Yeah, yeah, I know...but it's the truth)

A bit more on shaders. They aren't in games currently really, save for AquaNox, but there is a lot of clamor for Torque support for them (though I think what everyone means is "Please write shaders for us so we can use them") and if the engine is to scale with the times I guess it's going to need to support them. Currently the state of affairs is this: ATI and some other vendor (I'm thinking Matrox, who else would it be, SGI maybe?) have agreed on the EXT_vertex_shader GL extension (which is how it got the EXT tag), nVidia uses a propriatary form, NV_vertex_shader. I doubt that ATI/Matrox(?) will budge on theirs, hopefully nVidia will support the EXT_vertex_shader extension, then we can dump the NV_vertex_shader support. The other possibility is that everyone will come up with a new one, and we'll have to re-write the shader layer, but since that shader layer is there, at least people won't have to re-write their shaders.

#5 My current list:

- (easy & almost done) Making the maximum number of mounted images variable (8/16/32/64)
- Ogg Vorbis support
- Something a little faster and nicer for collisions
- Some sort of event/trigger system for missions. More on this later.

#6 Hi All -

Dave Myers, Ryan Mette, and I (founders of 21-6) are excited about this project and will contribute what we can - keeping our schedules in mind, of course :) It is tough to take time away from Myrmidon but we believe its in all our best interest to work together and implement some of the more difficult features we all need in our game. To that end, the three of us each chose an area we believed we could contribute to in the short term:

Artificial Intelligence
Ryan has started designing/prototyping the AI for Myrmidon over the last few weeks. He has been able to get the enemies to do some basic things like find and kill you - both with projectile weapons and melee attacks (from the bug). We all think this is one of the major areas of development that TCP could tackle that would benefit just about any game.

User Interface
You may have seen a snapshot of the skinnable user interface I have created for Myrmidon. There is definately still some work to do in cleaning it up - as well as adding support for more common controls and possibly breaking free of the control profile system currently making life so difficult for complex controls.

Terrain Enhancements
There are two enhancements we want to make to the terrain engine which are allowing for various size heightfields and support for multiple heightfields in a single terrain. These will be large efforts but is an area that many people have asked about in the forums. Dave has posted a thread on this topic already, but this forum seems a more appropriate venue for a discussion/project of that magnitude.

Justin Mette
21-6 Productions

#7 Thanks for the input guys..

I'll be writing a complete breakdown of "project idea's" sometime tonight. But from this thread so far, weve got a few.

Shaders - Now although shaders arent implemented in a standard way, there is no reason for us not to implement a shader system. One that can be "compiled" down to the native shader system of whatever render platform we are using. Quake 3 uses shaders for geometry and models, essentially we could use the Q3 shader definition almost verbatim and still have it work (the Q3 shader definitions still work with a fixed render pipeline).

Shaders is going to take a LOT of effort though, not only because of the "how do we break the torque shader language down into native shaders" but also because it requires a lot of support code in the shape loading (which if youve noticed is pretty funky! :))

Shaders is going to be a considerable effort, so its going to require at least a team of 3 people, with some input from Tim or one of the guys on implementation.

One of the offshoots of Shaders is that it free's us up a lot to write different render methods without affecting the torque core code. (So cel shading would essentially be a freebie).

I'd like to take a stab at leading the shader efforts, so I'll write a proposal document for the TCP Shader Project.

Collisions:

Its pretty clear that there is a bottleneck somewhere in the physics/collision code. Ive not been into this code at all yet, so I'm not sure what it is, but once Tim's happy with the new code he's altering, I propose we setup a TCP project that looks at the current implementation, first effort would be to profile the current technique, see if there is an obvious bottleneck, determine what (if anything) needs fixing. Once we have that, then the project can move onto implementation of a new method to provide a solution.

Anyone want to lead the collision/physics efforts?

AI: There's clearly a need for more work on AI. I agree with Ryan in that I see a need for a "lite" AI, which is effectively a very simple "scripted" object. I'd like to see this tied into a flexible scripting system at some level too (for instance, path following objects, simple bahaviours etc).

There's the "deeper" player style AI which is more Bot based, I guess the aim there is to allow it to be used as an opponent in a single player game.

Perhaps thats a good breakup point, simple and complex AI.

Anyway, does anyone want to lead the AI effort? seems like there should be an AI project to try and at least nail down some common ground, the usual stuff like pathfinding etc (core AI territory). I'd like to see a Project proposal that provides some inter-game flexibility here. AI at its core should be flexible, with the game specifics being built up on-top the flexible core. Its the core we need.

User Interface:

The 21-6 guys have this quite well under control, I'd like to see them getting some feeback from others to see if theyve dotted all the i's and crossed all the T's.

Anyone on the 21-6 team want to lead the ongoing UI project? basically just need a quick explaination of the current system you have implemented, so that others can discuss and contribute.

Terrain:

Terrain is another quite large project. There are quite a few requirements for the terrain ive seen on various forum posts. I'd initially like someone to lead this effort by making a list of requirements for the terrain, take a look at the current code and asses what changes can be implemented without significant alteration and which require major changes.

Part of the terrain project would mean updating and altering the editing interfaces.

So who wants to lead the Terrain Project? any takers.

I'll get Rick to add a new forum for the "projects" and add each of these projects as "blank template" projects.

We kind of need some people to step up to the bat and take a shot at leading some of these things (not necassarily all at the same time :))

Obviously there's a few projects that could be considered "underway". i.e. the AI, the UI and to some extent the Collision/Physics, I propose that currently we concentrate on making those projects useful, with shaders and terrain coming later once we've got enough people together to tackle those things.

So right now, we need organisers for those three projects (with UI being fairly obvious to be led by the 21-6 guys).

I'll join in with the AI efforts for now, linking in the movingInterior and breakables into "Scripted AI".

I'll get those projects setup, if you take a look in the threads for each project when I get the forum online and register your interest (or even offer to organize the efforts) that will get us underway.

PS: If youre planning on organizing one of these projects, please stop by and take a look at the "Organizers responsibility" thread under the getting started forum. I'll put down there the (as minimal as possible) guidelines required for being an organizer of a TCP project.

Phil.

Phil.

#8 Phil, I'll volunteer to lead the UI project.

PC: Thanks, thats what I hoped to hear, I'll create the project for this and put you down as lead with a request for any interested parties to get in touch ok?

#9 I'm seriously interested in the terrain project, and have started digging into that code to see how it works. I know that others here on GG have also started doing some research there (at least one or two others for sure). I'd be willing to lead the effort, but if there is already a well-experienced person out there willing to do it, I'll defer to them and help out.

Dave Myers
21-6 Productions

#10 I just thought of another area which TCP might fit well - engine robustness. For example, the engine crashes pretty hard if it doesn't like your video card for whatever reason. Also, the team has been experiencing memory leaks on Win9x platforms that we have yet to investigate but that could be problematic.

I know the engine has been out in the market for a long time and most of it is probably quite stable but there have been alot of changes in the last 6-8 months (including when all T2 IP was ripped out) and there will be many more changes to come. Making sure we are well tested and stable before moving ahead much farther would probably be in all our best interest. Maybe a QA project?


PC: Absolutely, I was thinking that Joel Baxter would head up this effort, he's been doing great work in that area and its important for all of us that it continues. Thats another sure TCP project

#11 I'd like to add ADO support to the scripting engine, to support generic database access.

That actually brings up another point, which is that we should really make an effort to keep everything as cross-platform as possible. I know there is a signifigant community of Mac and Linux guys here, so for people that are looking at stuff like UI, please keep them in mind...

Josh

#12 You can put me on the Collision team (maybe not as a leader of this task as I do not know if I will fill all needed criteria to be the organizer guy), and also on the Shader team as co-worker.

Concerning the collision system, I already profile the collision system with the PROFILE tag in Torque (I should dig in my hard drive to find again this log ;)) and I'm working on it at the moment : it's causing me very bad headache ;).

#13 I'd like to be involved in the AI plan for TCP. I haven't worked on any AI before Myrmidon although it's something I've always been interested in.
Someone else may be more qualified than I to lead this team, I surely would do so if needed to.

Ryan Mette
21-6 Productions


PC: Ryan, I think either you or Pat should lead the project, that doesnt imply you do all the work, just that you take a major role in the design and implementation plan.

#14 Stick me on the Shader team, and if the AI team needs me, I'll try to do some of their grunt work. I bit off way more then I could chew when I told Tim I'd do the AI. The first thing he said was, "really?" and my first thought was, "Sure...how hard can it be?" From that point on, the project was doomed ;-)


PC: Pat, thats what TCP is all about, spreading the workload a little, there are enough people interested in most subjects to make it a little less painful for everyone. Youve got a pretty good idea of how the AI code is now, how about leading the effort (i.e. just trying to organise how things should be done, it doesnt imply you do all the work).

#15 I am, as always, working on collision for players. On the IRC channel, I talked with Luigi Rosso, and along with a few tiny suggestions from me, he greatly expanded my hitbox code. He is a bit busy now, but should send me the tutorial *soon* (next 1-2 weeks). After I implement his stuff, my collision code will support:
1. Collision against individual limbs on the player, for both projectiles AND close combat weapons.
2. A completely new clos combat weapon script class and associated code to replace the rather disgusting hack from the last version.
3. If you want a tutorial, instead of just the code, it will have COMPLETLEY redone comments (the last ones were terrible, tacked on at the end when I was tired... :)
4. Support for loading collision details onto the player model DIRECTLY from the player.dts (the previous version required you to define the sizes in teh code)
6. (The coolest one: ) Support for projectiles that can stick into the player model. Example: You fire an arrow, and it hits the player in the left forearm. THe arrow would stay exactly where it hit, and animate as the limb moved.

Out of all of those, the only one not completely working yet is number 4. If you wish to give me a hand, check out my thread on the torque engine forum... any help would be greatly appreciated (I have been trying for over a week to find one last smal little error... :/ )

Once I am finished with that, I will be done with collision. I would be VERY interested in working on the AI after that, as I absolutely love AI.

#16 Guys, just wanted to know if the method of response is appropriate, Ive been sticking little comments into the posts to reply to you individually. If any of you dont like that idea, just let me know and I'll go back to just adding onto the thread.

I get lost when too many posts come along myself :))

Phil.

PS: Ive got control of the forums now, so I can create the TCP projects tonight.

#17 :( ... no answer in my post ... :P

#18 We could probably create diff threads ourselves with new proposals instead of stacking them all in here - lol. The only thing thats tough about editing our posts is that we dont get email notifications :(

#19 Phil, I just read your edit to my post again and realized there was a question in there. My answer is "yes" :)

#20 Phil: while it's useful for me to look back at my proposal and see how you responded, it's hell to scan back through every previous proposal by other people and see how they have evolved.

So proposals really need to go into separate threads.