A couple of people in the rage post thread mentioned forking the Spring engine to make an open source ZK-specific engine, with the possibility of raising money for a freelance C++ coder to do the job. Doable? Pros/Cons?
+1 / -5
|
Most coders will be afraid of reading such ammounts of code, which probably are a giant spaghetti ball of code, doom and destruction
+2 / -0
|
you don't need to fork it to do that. improve the engine and send your patches. to get your patches accepted some minimal requirements have to be met: - code needs to be commented - has to be clean, readable (=maintainable) by others - doesn't introduce new horrible bugs that are maybe not all points, but if you follow that advise it shouldn't be a problem to get a patch accepted. pros: you don't have to worry about anything / anyone cons: huge ammount of extra work as you have to do everything yourself which was already done by other people (homepage, repository, buildbot, lobby server, autohosts, lobby, validation tests,...)
+7 / -0
|
Assuming you get 1 guy to do it: Pros: I don't see any Cons: you become dependent on a single individual C++ is not the problem. Sure, its not the easiest language, but the complexity is in the code, not in the language syntax or constructs. A huge effort is required to understand enough of the code to improve it. If you expect to get help from current engine devs to help you to understand the code while you do not intend to give back (because you fork instead of becoming part of engine devs), then you'll be disappointed. If you can get 3 devs, then it may be doable. But I still don't see the point of not contributing to the engine codebase and fork it.
+3 / -0
|
The real issue here is where would zk get a cpp developer, not how/if to work with current engine team. However, it has been raised that currently engine receives very little testing by its developers, which leads to all kinds of regressions. Maybe, instead of forks, people should help test it more. (up to and including repeated commits of non-compiling code, because buildslave is responsible for building)
+3 / -0
|
I think that the main problem is not that spring and ZK are for some reason incompatible, but that the test engines are not tested enough with ZK. If more people would test the latest engine more often and report bugs there would be less instability. EDIT:     Anarchid said it just a few seconds before me!
+3 / -0
|
>you don't have to worry about anything / anyone This would be the main benefit. The engine forked would probably be .91, because that works best for us. I think the problem that keeps happening is that zero-k performance is harmed by things that help other games, and vice versa. Also we could make Linux static builds, which are not available for current .91 >huge ammount of extra work... (homepage, repository, buildbot, lobby server, autohosts, lobby, validation tests It could probably sit in the same github where the zero-k source does. the lobby server has already demonstrated the ability to use 2 engines simultaneously. IDK about buildbots though.
+0 / -1
|
> Cons: you become dependent on a single individual" thats one of the big problems with zervers fork, too, or more general: the problem with closed source. > that the test engines are not tested enough with ZK" Thats true, as engine dev i can't regret that, too. What would help need is some automatic (!) regression testing like: - unit is spawned, loaded into transport, than unloaded. if after time x, unit and trans aren't at specific position, test failed - lua unit tests for benchmarking performance: repeatidly call lua functions and take the time it needs - ... what ever automaticly can be tested it is out of the scope for engine devs to test all games with it, this is why we need automatic tests and still additionally the manual tests by users. see also http://springrts.com/phpbb/viewtopic.php?f=21&t=27928
+3 / -0
|
quote:
The engine forked would probably be .91 |
Then what will happen when the engine adds an effective multithreading model? (or any other major improvement) You expect a single guy will backport all the multithreading related changes to the ZK fork? Or you think its wise to ignore future engine improvements because "engine devs are idiots who do not care about zk special needs"?
+2 / -0
|
quote:
It could probably sit in the same github where the zero-k source does |
Zero-k is not sitting in a github currently. Sad but true.
+0 / -0
|
These "lets fork it" guys are either stupid or I dont know what else to say, if you wanna fork it go and do it instead suggesting "brilliant" ideas, just like zerver provided you have time and required brainpower. I mean wtf you are thinking you do nothing to improve current engine and wanna fork it already LOL. Just close the damn thread, its totally idiotic. Forks happen when one dev wants do this other do that and they cant agree on something thats how zerver fork happened. But now goal is same and the point of your "biriliant" fork then is?..  And about spaghetti code, open source projects mostly have nice and clean code, probably because its written by people who like coding, and closed source is spagheti whatever crap which just works(for now), because it must be written faster quality mostly doesnt matter( my job :( ).
+1 / -0
|
There is absolutely no point in talking about a fork unless YOU are going to do it or YOU know someone who is going to do it. But as several people have said, even if you had someone who was prepared to work on the engine specifically to benefit Zero-K, they would be better off making 95 work better with Zero-K than forking the 91 engine.
+0 / -0
|
I'm against forking. Bugs crawl in into any sufficiently large project, be it ZK-only or not. It's better to try getting things right, talking to the Spring devs about what they are doing, why they are doing it, and how can we help improve it. They most certainly participate on the development of one of the Spring games. Is it BA? Is it NOTA? Is any Spring dev around here? Maybe we could talk to him and get some feedback on the engine development. On a side note, I think we don't need to get a new Spring engine every time a new version is released. We could set up a "Beta" server, where interested people could test a new engine (preferably using a profiler) so that we can see which parts of the code would cause problems. If you ask me what the Spring devs are certainly doing wrong, I would tell you that it is the release of major versions instead of minor patches, like most other developers. With so much change between versions, it is quite hard to pinpoint what is going wrong.
+0 / -0
|
> If you ask me what the Spring devs are certainly doing wrong, I would tell you that it is the release of major versions instead of minor patches, like most other developers. With so much change between versions, it is quite hard to pinpoint what is going wrong. It's kind of irrelevant to us when the Spring devs decide to increase a version number. For ZK we decide on a spring version to use. It could be 91, 95, or 94.1242.697. What we need to do is test zk on these engine versions. We do, just not often enough.
+0 / -0
|
quote:
I mean wtf you are thinking you do nothing to improve current engine and wanna fork it already LOL. Just close the damn thread, its totally idiotic. |
Is that really the best you can contribute to this thread? Really? There is nothing like a coherent argument in your post.
+0 / -0
|
quote:
It's kind of irrelevant to us when the Spring devs decide to increase a version number. For ZK we decide on a spring version to use. It could be 91, 95, or 94.1242.697. What we need to do is test zk on these engine versions. We do, just not often enough. |
In fact, it is very relevant to us. We don't get to test unreleased half-baked svn commits to the Spring engine, do we? We only test the release versions of Spring. And if there are too many changes between one version and another, we cannot pinpoint for sure what is going wrong. Now, 95.0 has an insane amount of changes. I've gone through the changelog and it seems to me that it has about 3x to 4x more changes deemed to break backward compatibility than the previous releases after 91.0. If the update had been smaller, we could possibly find the changes that are giving us headaches. I'm not sure it is possible to test it all as it stands. I've noticed a lot of Lua changes in the changelog. Many functions had their arguments and return values modified. Since ZK uses a good amount of Lua scripting, I think the ZK devs should prioritize checking them, if they decide to make ZK compatible with the 95.0 engine.
+0 / -0
|
quote:
We don't get to test unreleased half-baked svn commits to the Spring engine, do we? |
You do! that is what the bleeding edge host is for. It runs the latest development version of spring and ZK.
+0 / -0
|
quote:
svn commits to the Spring engine |
There are no half-baked svn commits to the Spring engine. There are half-baked svn commits to ZK. There are imperfectly tested git commits to Spring. (vcs naming confusion error)
+0 / -0
|
I thought that the Bleeding Edge didn't include the revision versions of Spring too. How often is it updated to a newer Spring commit version?
+0 / -0
|
quote:
There are no half-baked svn commits to the Spring engine |
. I didn't mean any offense, Anarchid. I thought we only got to test Spring released versions, not the commits between versions, but it has already been pointed out that I'm wrong. Edit: I'm not sure I'm wrong about the Bleeding Edge. It does not seem to be using the latest Spring commit version. It is on 94.1 until this very day.
+0 / -0
|
