I suggested a while ago about a code freeze to work on z levels and npcs. I was told no because there was a concern that some people would be put off by this. Here is another idea. I put it in the needful things thread, but it really doesn’t below there. Kevin asked for easy things. This won’t be easy. I also want to add that I am NOT attacking any developers. I greatly appreciiate all the hard work you put in. However, the lack of Z levels and NPCs is a major limitation. I don’t think we will ever get z levels without a change.
Branch the code.
Branch 1: same as now. People can keep adding content and add what they think will be fun
Branch 2: code freeze to only work on z levels and npcs and changing the underlying mechanics as the developers see fit.
Once these are done and the code is revised (this will probably take a long time. end of the year and/or into next year). It can be unfrozen. People can port their content over. If they don’t want to, we can have 2 Branches that will serve as variants. Variants can be a good thing. Look at Nethack and Angband.
We had a bad experience with the first Variant (metal gear solid). The guy was a good developer, but was a jerk. I have heard that Wales wants to do his own thing and is ‘bitter’ or whatever about DDA. I don’t care and don’t want to get in the middle of that. I don’t see why we can’t as a community be ok with variants. We don’t have to argue about what is better. Its a single player game… Diversity can be fun. I’m sure we can get along. Those who don’t can go to another forum.
As we’ve said many times before, people are only going to work on things like NPC’s and z-levels if they want to work on them, regardless of what we do. Cataclysm is a volunteer project after all, not something anyone is being paid to do. All freezing the codebase is going to do is stop all development, which is not a very good thing (besides, it freezes for you when you branch it to work on it anyways, and most merging afterwards takes only a little bit more work relatively). That said we do currently have a bounty system up, with the first issue paying out $330 for anyone who manages to complete it to the specifications successfully.
There’s a misunderstanding here about how collaborating with git works. When you make ANY change, you make a branch, add things, then merge it back in.
If you want to collaborate on some specific thing, you’d just start your work, then make a pull request with your branch to let everybody know about it, then if people want to help directly, they can make pull requests to that branch. Making an “official” branch is actually counterproductive, because then it brings me, Ka101 and Rivet (as the current comitters) into the loop even though we don’t need to be, then every change would have to go though one of us, likely slowing down collaboration.
This kind of long lived feature branch has happened a few times, but the norm is that people break big features up into small changes and push them to the project a piece at a time, because if you don’t the merge process at the end gets more and more painful. Also big merges lead to new bugs scattered across the codebase pretty much every time it happens.
Historical note, the MGS mod was not the first fork, it was the third. You don’t hear as much about the first two because we collaborated on IRC rather than on the forums, and the authors weren’t jerks, so there weren’t huge arguments about things. Those forks culminated in the classic zombie mode and dinocat mod once the project grew enough mod handling features for us to merge them back in. The thing about forks is they take a lot of extra effort on both sides to keep them running, to the point where it was less work to add a LOT of code to switch the various content on and off rather than maintain multiple forks.
Every change management software is different… branch is a common turn in other versions.
My take on this is that z levels are hard and will take a long time. It also appears they are not practical to keep current with the constant changes in code?
There will be some mechanism in GIT to allow to different development paths. These may or may not be fully merged back into each other. I think the only way to get z levels is work on them separately without any code changing. So I suggested a branch. There will be a mechanism in GIT to do this kind of thing. It doesnt necessarily have to be merged back in. It can be set up as a variant. Lots of roguelikes have variants.
I think if the framework is setup people who want to work on z levels can. By having a fork/branch or whatever its called in GIT(or even a separate variant), it might make it easier to do this.
You dont necessarily have to merge things back. You could have a variant. You could have some people who want to port their code over to a z level version, etc… It looks like merging will be a problem and that is a bottleneck. So maybe its time for a cataclysm variant with 2 different development paths? Would it need to be a separate project? I think for community involvement the same project would be better.
I have used alot of change management software over the users. However, only at the user level. They are all a little different.
Would having a separate development track for z levels help? so that whoever wants to work on this will have a baseline to work from?
Why split them into two at all? Z-levels and NPCs are gameplay, not content. If they relied on a very specific collection of code that is thrown off immediately when you add an item, you would need to split the game. But it doesn’t. And thus, a new branch isn’t needed. Z-levels and NPCs will be here at some point and making two variants would just cause more trouble down the line for entirely separate reasons. Don’t fix what isn’t broken, I say.
The problem with forking (making branches you will not merge back together) is it splits the developer and user base. you then either merge things across from one to the other to somewhat keep them in sync, wasting a lot of time doing so, or they start diverging, and similar features are implemented on both, wasting even more time.
More importantly for the discussion at hand, there is nothing about a fork that would make NPC or z-level work significantly easier, you’re working from a bunch of assumptions about the project and project development that are simply wrong.
The community will always be divided as far as what they want, so I think it’s best to leave the developers to develop what they see fit to work on (as roy said).
Personally, I would like to see the combat changes that GlyphGryph mentioned at one point get implemented soon, (kicking things through windows, dodging aside, etc.) but as long as more fun stuff is getting added, I don’t see any reason to complain. The game is free, after all.
If work continues, Z-levels and NPCs will probably get some love eventually.
I’d actually like to see if Whales manages to succeed in implementing Z-levels and complex NPC behavior in Cataclysm 2 that’s too difficult to implement this late in the development of DDA.
I’m secretly hoping to see Cataclysm 2: Dark Days Ahead be a thing at some point in the future, if whales succeeds in making it a good vanilla game anyways.
i do not feel need for z levels like in DF but adding multi story building what is possible alerday by player with debug menu maybe add to some high objets a binoculars what work like map console in lab but only 0 level and higher will be scouted for falling from building maybe just give player a warning “its bad idea to do it” or something like that maybe if we want make it more advenced allow players to fall down on 0 level if player have parachute or wings