The primary reason for forking was this: I TRIED to contribute to Sauerbraten, and Cube, but there was already so much fuss about 3 lines of code that it was pretty obvious that contributing wouldn't work. I just don't like Aardappel, and he doesn't like me. I tried to "resolve" it by talking to him but that didn't work either. Besides, many of my changes violate Sauerbraten's "simplicity" concept (which I generally like, but not always). Oh, and Sauerbraten isn't "moddable" in the same sense as, say, Quake is. You have to modify the engine code for even the smallest changes (at least it was that way when I forked, and as far as I know that hasn't changed at all). So forking was the only option. At first I planned to incorporate their changes into my code (and they would incorporate some of mine, if they wanted that) but I soon stopped trying to diff out the changes I wanted because it was too much effort (and I'm doing this for fun, not for money :).
And yes, some people in the Cube community make you think you'd rather not be a part of it. (The posting page says not to be a "potty mouth".) ;) |
 |
|
Re: why fork
posted by
Coz
@ 200.65.127.163
on Sep 28 2006 8:01 AM
|
|
I think forking is 'fine' as long as you go in a different direction. If you both reach the same end, it was for naught :s
But try to understand the developer's concept of the engine a bit: for example, let's put the hypotethical case where you want to avoid dependencies in a game, and are not willing to accept any patch that adds a new one. And suddently you get a patch with the features that users/you have been wanting for many months, but haven't been able to program because of time, but it adds various new dependencies that you don't know, and on top of that the person adds some other small changes that definitly shouldn't do (for example, changing the directory structure or the compiling process).
Should you reject the patch? should you add it even with the disadvantages? there is no clear answer, and no perfect solution. Even telling the person to modify the patch will put you in a 'mean' position, and you might even get negative publicity depending on how that person reacts.
I'm not telling you to scrap the fork, if you go in a different and incompatible direction it's fine, otherwise you will have some features that they don't and they will have things that you don't but you could have all that if there was some colaboration.
However it would still be nice if you posted patches in the mailing list that you think they are willing to accept. If you have just tried once sending a patch, maybe there was something particular about that patch. |
| |
|
[Reply]
|
|
Re: why fork
posted by
Coz
@ 200.65.127.163
on Sep 28 2006 8:03 AM
|
|
I think forking is 'fine' as long as you go in a different direction. If you both reach the same end, it was for nothing :S
But try to understand the developer's concept of the engine a bit: for example, let's put the hypotethical case where you want to avoid dependencies in a game, and are not willing to accept any patch that adds a new one. And suddently you get a patch with the features that users/you have been wanting for many months, but haven't been able to program because of time, but it adds various new dependencies that you don't know, and on top of that the person adds some other small changes that definitly shouldn't do (for example, changing the directory structure or the compiling process).
Should you reject the patch? should you add it even with the disadvantages? there is no clear answer, and no perfect solution. Even telling the person to modify the patch will put you in a 'mean' position, and you might even get negative publicity depending on how that person reacts.
I'm not telling you to scrap the fork, if you go in a different and incompatible direction it's fine, otherwise you will have some features that they don't and they will have things that you don't but you could have all that if there was some colaboration.
However it would still be nice if you posted patches in the mailing list that you think they are willing to accept. If you have just tried once sending a patch, maybe there was something particular about that patch. |
| |
|
[Reply]
|
|
Re: why fork
posted by
releppes
@ 147.139.129.10
on Oct 2 2006 11:49 AM
|
|
| Looks like my impression of the Cube* community is not issolated ;)
I like Cube and Cube2 for the simplistic approach to engine design. What I dislike about Cube and Cube2 is the narrow focus on (re)creating a been there done that style of gameplay.
Although this fork doesn't look too promising (yet?), I commend the author for his efforts. I'd personally like to see more forks based on this engine. Preferribly something new and original. |
| |
|
[Reply]
|
|
Moddable Engine => Gameplay
posted by
Anonymous
@ 217.227.216.137
on Oct 14 2006 12:07 AM
|
|
| The modability of the engine's fork is just the first step on your way to create a new gameplay. The most free 3D Shooters are somewhat Quake-Themed, though mostly lacking full-conversion attempts.
I'd be most willing to contribute if someone tried to create something between Enemy Territory (Classes, Objectives) and Ghost Recon (modern Combat). |
| |
|
[Reply]
|
|
|
Re: Moddable Engine => Gameplay
posted by
releppes
@ 147.139.129.10
on Oct 18 2006 10:46 AM
|
|
Yeah, me too.
I thought it'd be interesting to have a game/mod that removed ALL power ups in the game. Instead, have everything be an auto regenerating attribute, ...but with a twist.
You could auto regenerate your health, but you need to rest in order to do so. Resting could be anything not involving activity (ie: not shooting, running, etc...). While resting, you would slowing regenerate. However, at the expense of being frozen/vulerable, you could heal faster. This concept is akin to those old school turn based RPG games where you needed to rest in order to regain health. However, during a rest, you could get ambushed.
Ammo would be replaced with a strength attribute. Once you use up all your strength, you need to rest before you can shoot again. This is like mounted guns in WolfET. You can only shoot so long before the gun over heats.
Everything else like sprinting, invisibility, invulerability, flying, etc... would be a power attribute. And just like health and strenght, you only have so much before you have to wait for it to auto regenerate.
In efforts to promote teamplay and character development, allow the ability to heal others at the sacrifice of power (ie: like a medic), and allow the ability to increase someones strength (ie: reammo) at the expense of health (ie: like a field ops). These operations are like having character types in WolfET, however the roles would be defined base on how one plays the game.
Have all weapons be like a sniper rifle in WolfET. Meaning, the shot is more accurate or gives more dammage when the gun is steady. No more running at mach speeds doing back flips through the air and still getting a head shot off.
Allow promotion in the game based on the role your character is playing. For example: If you go around healing others (at the expense of your power), give a bonus of more power after 10 heals. If you reammo other by giving them strength (at the expense of your health), then give a bonus of more health after 10 reammos. A solder is a little different. All they do is kill. They don't directly help any teammate other than providing protection. So after 10 kills, give them a bonus of better accuracy, more dammage, etc... anything to help them be a better killer.
The concept behind such a mod would be ultra simplifying in game character management. No more searching around for power ups. Let the character take care of itself based on how you play. And you don't "choose" your character type. Your character type will be formed depending on how you play. Those were the ideas anyway...
|
| |
|
[Reply]
|
|
|
Re: Moddable Engine => Gameplay
posted by
Anonymous
@ 80.134.84.178
on Oct 31 2006 12:43 PM
|
|
| Really nice idea! I'd like to at least test it as a mod. But I think it would just work on larger scales (i.e. maps and number of players). And it lacks the ability of fast switching to a class that's desperately needed. But that will just result in new style of gameplay. But some sort of items/objectives are needed, it would not work on a simple deathmatch concept. |
| |
|
[Reply]
|
|
|
Re: Moddable Engine => Gameplay
posted by
releppes
@ 66.67.104.33
on Nov 3 2006 4:56 PM
|
|
| Agreed. These were just some random thoughts on gameplay modifications. The "character building" would take too long for a single game. I was thinking more along the lines of WolfET were you can build a character over the course of several missions (ie: level up...). As for having the ability to change character roles rapidly, there would be no need since any character can shoot, heal, reammo, etc...
As a death match game, this mod would probably suck. Maybe better for a CTF type of game. And you're right, you'ld need at least four person teams before strategies like healing and reammo, etc. would make any sense. However, because there really is only one type of character, it might bridge the gap between Quake style uni characters and defined character types like in WolfET.
It was just an idea of how to make a simple FPS with slightly more realistic gameplay.
|
| |
|
[Reply]
|
| |
| |
| |
| |
Multiplayer First Person Shooter
