Project 'brainstorming'
Moderator: General Discussion Moderators
- Slink
Not to be a dick, but...
- Posts: 1904
- Joined: Mon Aug 16, 2004 04:42 am
- Location: Niagara County, NY
Project 'brainstorming'
Instead of posting another in the previous thread, I have created a new post here.
* Regarding switching engines, in combination with the "only the TFn team can use Blood media" agreement, as long as the team agrees that a member is a member, that said member can take on a new engine for TFn, right? (Provided it is a group agreement.)
* Also, how many of the developers own a copy of Half-Life 2 (or any HL2 sequel), Counter-Strike:Source, or TeamFortress2 on "Steam"?
I understand the points of staying open-source.
* Regarding switching engines, in combination with the "only the TFn team can use Blood media" agreement, as long as the team agrees that a member is a member, that said member can take on a new engine for TFn, right? (Provided it is a group agreement.)
* Also, how many of the developers own a copy of Half-Life 2 (or any HL2 sequel), Counter-Strike:Source, or TeamFortress2 on "Steam"?
I understand the points of staying open-source.
No offense Andrew, but you are doing exactly what I think we should stop doing: keeping the discussions about TFn in The Cabal forums. Could you please move this thread to "Transfusion Discussion" ?
As for HL2 / Steam, I know you're a big proponent of that. Source is probably a very good engine (I haven't really looked at it honestly), and I certainly consider the release of Steam as one of the major steps in the recent gaming development / publishing history. But none of them are open-source, and so for me it's a non-starter.
Also, we already have a lot of resources in Q3 compatible formats (meshes and maps, animations too I think). So again I think the Q3 engine would be the best choice if this project decides to switch to another engine in the near future.
As for HL2 / Steam, I know you're a big proponent of that. Source is probably a very good engine (I haven't really looked at it honestly), and I certainly consider the release of Steam as one of the major steps in the recent gaming development / publishing history. But none of them are open-source, and so for me it's a non-starter.
Also, we already have a lot of resources in Q3 compatible formats (meshes and maps, animations too I think). So again I think the Q3 engine would be the best choice if this project decides to switch to another engine in the near future.
- predator
- Lead Mapper
- Posts: 1100
- Joined: Sat Aug 14, 2004 12:51 pm
- Location: Warsaw, Poland
- Contact:
Switching to Q3 would certainly be the easiest thing.
As for source engine - I really don't know a great deal about that engine. I played HL2 like 2 years ago and that's it. I'm sure you know what you're saying Andrew, I just can't really make a comment on this as I simply have very limited knowledge of source and steam.
As for source engine - I really don't know a great deal about that engine. I played HL2 like 2 years ago and that's it. I'm sure you know what you're saying Andrew, I just can't really make a comment on this as I simply have very limited knowledge of source and steam.
- Slink
Not to be a dick, but...
- Posts: 1904
- Joined: Mon Aug 16, 2004 04:42 am
- Location: Niagara County, NY
I would move this thread, but I don't seem to have administrative privileges to this forum area.
It sounds like Q3 really would be an easier switch. I honestly don't know the implications or requirements of switching to Source, pertaining to our existing content (as far as models go). As far as sound, maps, and art; I think those would all be easy batch conversions.
Thanks for the speedy replies!
On this topic, it seems that the Q3 engine is written in C. SO, would we have to re-write most of the code?
Basically, I believe that Q3 uses the same general language as Q1, while removing existing limitations of QuakeC. (Implementation is different, therefore if we wanted to use existing code, new code would have to be written to allow direct porting of existing quakec code into the Q3 engine, unless some QuakeC-to-Q3 port already exists. That would be a bit ridiculous and defeat the purpose of switching to Q3.)
QuakeC is a "scripting language" (which is limited) while Quake3 uses C libraries, yes?
It sounds like Q3 really would be an easier switch. I honestly don't know the implications or requirements of switching to Source, pertaining to our existing content (as far as models go). As far as sound, maps, and art; I think those would all be easy batch conversions.
Thanks for the speedy replies!
On this topic, it seems that the Q3 engine is written in C. SO, would we have to re-write most of the code?
Basically, I believe that Q3 uses the same general language as Q1, while removing existing limitations of QuakeC. (Implementation is different, therefore if we wanted to use existing code, new code would have to be written to allow direct porting of existing quakec code into the Q3 engine, unless some QuakeC-to-Q3 port already exists. That would be a bit ridiculous and defeat the purpose of switching to Q3.)
QuakeC is a "scripting language" (which is limited) while Quake3 uses C libraries, yes?
- Slink
Not to be a dick, but...
- Posts: 1904
- Joined: Mon Aug 16, 2004 04:42 am
- Location: Niagara County, NY
LoL indeed it is... yet this "new" reasoning stands the test of time and trial, I believe. DP has not quite met our expectations due to the use of the limited QuakeC. Is there any way to implement game code other than QuakeC in DP?DustyStyx wrote:I could move it, but why? We've had this discussion before. It's even in the FAQ for crying out loud.
- Slink
Not to be a dick, but...
- Posts: 1904
- Joined: Mon Aug 16, 2004 04:42 am
- Location: Niagara County, NY
QuakeC sometimes makes things difficult, or near-impossible.
http://en.wikipedia.org/wiki/QuakeC
http://en.wikipedia.org/wiki/QuakeC
Well, given the topic of this thread, I think we will not only talk about "switching to the Source engine", but about the general goals and technical choices of this project.DustyStyx wrote:I could move it, but why? We've had this discussion before. It's even in the FAQ for crying out loud.
Also, more generally, I think all discussions and information that don't absolutely need to be private (because it contains passwords for instance) should be made public. I know I'm repeating myself here, but I firmly believe it's a good and easy way to keep non team members interested in the project, to get feedback from them. And it also lowers a bit the bar of entry when someone thinks about contributing.
All DP mods I know of use QuakeC, so even if there's another way to implement game code in DP, it probably won't be mature, stable and/or tested enough for us to use.Slink wrote:Is there any way to implement game code other than QuakeC in DP?
Netplay with Unlagged is very playable. Tom and I would load up his Q3 Bloodbath maps on Q3A and have a ball. Now that OA is out, it'd be trivial to get more people to playtest a few things. All we'd have to do is install OA and get Tom's Bloodbath maps; they work for the most part. Just a few items won't render, but the maps load fine.
- Slink
Not to be a dick, but...
- Posts: 1904
- Joined: Mon Aug 16, 2004 04:42 am
- Location: Niagara County, NY
That is to say "After the Q3 transition"? I'm a little lost.DustyStyx wrote:Netplay with Unlagged is very playable. Tom and I would load up his Q3 Bloodbath maps on Q3A and have a ball. Now that OA is out, it'd be trivial to get more people to playtest a few things. All we'd have to do is install OA and get Tom's Bloodbath maps; they work for the most part. Just a few items won't render, but the maps load fine.