Moving interiors - Changes to the head!
by FruitBatInShades · in Torque Game Engine · 01/26/2005 (4:59 am) · 16 replies
Does anyone know if the moving interiors resource will make it into the head? I really think we should have moving DTS and DIFs in the core engine. I can't think of many projects that don't require doors or moving items (Except for simple style games, which is mainly the type that people produce for garage).
The demo code seems mainly aimed at FPS style games but LORE is the only one that comes close. If a few features (which already exist as resources) made it into the head, FPS development would be more viable.
Missing features for FPS
Dynamic interiors
The moving interiors resource is a hefty change to the engine. It not a trivial task and once merged in, updating the codebase is a nightmare. What about extracting the interior code into a class library/dll and keeping two versions. The current one and a dynamic one. Then its just a case of selecting the interior lib to use.
I know this is a HUGE undertaking but the dividends would surely be worth it. I just wondered whether this might make it into the roadmap as the engine gets changed for TSE.
One other thing, at present doors can only exist in LOD0, that can be a real problem as you run up to a building and a door suddenly appears!
Active shapes/triggers
People are constantly asking for ladders, ropes, lifts and platforms. Would it be possible to create a new shape class that contains a trigger to acivate a player function? e.g. players collision box touches activeShapeLadder (ASL). ASL fires a player trigger 'player.onLadder' which allows the coder to change the bounds, animation and movement cycle.
Any thoughts/ideas?
The demo code seems mainly aimed at FPS style games but LORE is the only one that comes close. If a few features (which already exist as resources) made it into the head, FPS development would be more viable.
Missing features for FPS
Dynamic interiors
The moving interiors resource is a hefty change to the engine. It not a trivial task and once merged in, updating the codebase is a nightmare. What about extracting the interior code into a class library/dll and keeping two versions. The current one and a dynamic one. Then its just a case of selecting the interior lib to use.
I know this is a HUGE undertaking but the dividends would surely be worth it. I just wondered whether this might make it into the roadmap as the engine gets changed for TSE.
One other thing, at present doors can only exist in LOD0, that can be a real problem as you run up to a building and a door suddenly appears!
Active shapes/triggers
People are constantly asking for ladders, ropes, lifts and platforms. Would it be possible to create a new shape class that contains a trigger to acivate a player function? e.g. players collision box touches activeShapeLadder (ASL). ASL fires a player trigger 'player.onLadder' which allows the coder to change the bounds, animation and movement cycle.
Any thoughts/ideas?
#2
01/26/2005 (6:57 am)
@Tom: aren't x,y,z, animation and vector sent in the packet? If the moving parts are done on a server thread, that thread could update the players packet to reflect these changes maybe? 
#3
01/26/2005 (8:23 am)
Well Tim mentioned a long time ago that lifts and doors pushing players was really tricky to get working citing Tribes 1 as the example. Also notice they didn't exist in Tribes 2. 
#4
01/26/2005 (8:38 am)
I believe someone from GG even said that the Elevators in Tribes 1 was a hack. 
#6
01/31/2005 (2:50 am)
Nice going matt, are you going to release a resource ;)
#7
Well, maybe there is and I just don't know?
01/31/2005 (5:52 am)
I would like to know how the process is with GG: let's say everyone agrees that a certain ressource is valuable and useful; who decides if and when this ressource is going to part of HEAD (or the SDK in general)? There should be some sort of reviewing process, and a person/unit in charge of providing this.Well, maybe there is and I just don't know?
#8
01/31/2005 (5:56 am)
I *strongly* agree that we don't need yet another resource for this sort of feature. Let's get something into HEAD already.
#9
01/31/2005 (7:00 am)
I put that idea over a long time ago but I think garage has a lot on its plate. I personally think they should re-organise torque to be more class oriented/plugin architecture so we can safely and easily change areas. Problem is, although this would adds lots of value to torque, its a big job to undertake.
#10
If Matt implements and submits a patch that works with the current HEAD, then the only work for them is integration of the patch.
The forums and resources are used to provide support and examples of how to use the feature.
If a bug is found and community member can report it and anyone can fix and submit a patch for it.
All that is needed is someone to implement it and GGs agreeing that it is valuable to the engine and deserves to be part of the official Torque release.
Ben you can now come and correct me. =)
01/31/2005 (7:09 am)
I disagree that it's that much work for the GGs staff.If Matt implements and submits a patch that works with the current HEAD, then the only work for them is integration of the patch.
The forums and resources are used to provide support and examples of how to use the feature.
If a bug is found and community member can report it and anyone can fix and submit a patch for it.
All that is needed is someone to implement it and GGs agreeing that it is valuable to the engine and deserves to be part of the official Torque release.
Ben you can now come and correct me. =)
#11
Once a resource gets into the engine itself officially, then GG must support it and maintain it ever after. They cannot ship an engine that e.g. only has working ladders on Mac, but not Windows (etc and just a hypthetical example)
Thus its a balance of what is deemed "essential" and what is OK as a separate resource.
With that said - moving platforms is something "all other engines" have, and should be part of TGE imho. The work Matt has done goes even beyond the initial resources, and thanks Matt!!!
01/31/2005 (7:47 am)
There is more to it than just applying the patch.Once a resource gets into the engine itself officially, then GG must support it and maintain it ever after. They cannot ship an engine that e.g. only has working ladders on Mac, but not Windows (etc and just a hypthetical example)
Thus its a balance of what is deemed "essential" and what is OK as a separate resource.
With that said - moving platforms is something "all other engines" have, and should be part of TGE imho. The work Matt has done goes even beyond the initial resources, and thanks Matt!!!
#12
Certain things seem to change depending what object you are calling (rotation is a prime example) and it seems that certain classes would be more logical elsewhere. If this was undertaken, it would be a good time to finish the documentation and get them done together.
For those that don't know, this process or re-organising the code is called 'refactoring' and is a lot quicker and easier than you might think. It just requires an understanding of the codebase (which rules me out :oD ), a clearly defined target structure and a lot of Ctrl-C and Ctrl-V.
I have a vague memory that someone was attempting this a while back but cannot find the resource. Problem is, unless garage actually implements and supports the system, it will be useless. Please have a think about a process and guideline system garage, it will make new features a lot easier and the power of torque will develop even quicker than it is.
01/31/2005 (7:51 am)
If the source code was branched off into logical components then altering it would be a lot easier. I must admit that I am having a hard time deciphering torque as I come from an OOP background and am used to well defined interfaces and process logic.Certain things seem to change depending what object you are calling (rotation is a prime example) and it seems that certain classes would be more logical elsewhere. If this was undertaken, it would be a good time to finish the documentation and get them done together.
For those that don't know, this process or re-organising the code is called 'refactoring' and is a lot quicker and easier than you might think. It just requires an understanding of the codebase (which rules me out :oD ), a clearly defined target structure and a lot of Ctrl-C and Ctrl-V.
I have a vague memory that someone was attempting this a while back but cannot find the resource. Problem is, unless garage actually implements and supports the system, it will be useless. Please have a think about a process and guideline system garage, it will make new features a lot easier and the power of torque will develop even quicker than it is.
#13
But really there isn't that much that is missing from standard Torque that is needed.
01/31/2005 (8:16 am)
I guess i'm in favor of more community involvement in the expansion of the engine. Including some of that maintenance. I think GGs is focusing on having Associates do some of that work with coordination with them.But really there isn't that much that is missing from standard Torque that is needed.
#14
The problem at the moment is that if someone creates patch its only useful for that version. If the author goes away and no-one picks up the gauntlet, it gets harder and harder to merge that resource sucessfully. Merges are a pain and not the best way to change the engine. It would be much more useful to have replacement classes that you instantiate, instead of the default ones. Thats a no-brainer.
Download new interior classes, backup old, replace, recompile. If the interfaces were standardised internal changes would never break the engine. This is the way the rest of the coding world operates now. Game code always seems to be less structured because you can get slightly better performance.
What I'm saying is that if there was a procedure for extending/changing the engine then the community could help MORE!
01/31/2005 (8:42 am)
@Tom: Garage need to set up the procedure otherwise we will be no further along than we are now.The problem at the moment is that if someone creates patch its only useful for that version. If the author goes away and no-one picks up the gauntlet, it gets harder and harder to merge that resource sucessfully. Merges are a pain and not the best way to change the engine. It would be much more useful to have replacement classes that you instantiate, instead of the default ones. Thats a no-brainer.
Download new interior classes, backup old, replace, recompile. If the interfaces were standardised internal changes would never break the engine. This is the way the rest of the coding world operates now. Game code always seems to be less structured because you can get slightly better performance.
What I'm saying is that if there was a procedure for extending/changing the engine then the community could help MORE!
#15
01/31/2005 (10:29 am)
Matt's changes are going in to head. This is part of the interior improvement that he has been working on, see his last plan about map2dif.
#16
If the whole engine core could (gradually, perhaps, then sprung on us as a 2.0) be refactored this way, it would provide more value for the buck as well as facilitate more community improvements with less issues such as this. (And even give everyone an incentive to upgrade to 2.0 for another round of $100 registrations to support the effort.)
US$0.02
02/15/2005 (1:59 pm)
Quote:It would be much more useful to have replacement classes that you instantiate, instead of the default ones. Thats a no-brainer.Hear, hear! Just look at how powerful Melv May's contributions are. Torque2D seems very OO and extensible from what I understand.
Download new interior classes, backup old, replace, recompile. If the interfaces were standardised internal changes would never break the engine.
If the whole engine core could (gradually, perhaps, then sprung on us as a 2.0) be refactored this way, it would provide more value for the buck as well as facilitate more community improvements with less issues such as this. (And even give everyone an incentive to upgrade to 2.0 for another round of $100 registrations to support the effort.)
US$0.02
Associate Tom Spilman
Sickhead Games