Feedback is much appreciated.
Also I made small intro scenes for the first three worlds. Let me know what you think.
* Swimming sucks! I got stuck swimming for no good reason three times. I think the vertex adjustment code should check if the clonk would be stuck if vertices are changed and retry the adjustment for a few frames later in that case
* When I played it, I could just dive all the way down to the amethysts. I didn't build anything. It can easily be finished in five minutes that way. Is this intended?
* The intro looks a bit weird when both clonks look the same. But I don't see a good solution to this.
* Would you suggest to add more granite in the way so that you need to have more explosions? How did you manage to dive so deep without getting more air? Did you use the caves which appeared after explosions? The idea behind this goal and landscape was that the player at least builds a single pump and power supply for it, with which he can drain the veins. For people who like settling one can even build an array of pumps and go crazy with the draining. Maybe I should add more granite, on the way down and on top of the rubies? What do you think?
* We could make the engine give the player different skins by default, so that he or she has different clonks in his crew.
> * Would you suggest to add more granite in the way so that you need to have more explosions? How did you manage to dive so deep without getting more air? Did you use the caves which appeared after explosions? The idea behind this goal and landscape was that the player at least builds a single pump and power supply for it, with which he can drain the veins. For people who like settling one can even build an array of pumps and go crazy with the draining. Maybe I should add more granite, on the way down and on top of the rubies? What do you think?
I think it's good to have an introductory world that is very easy so it's fine as it is. If you want to make it harder, maybe the water area could be extended slightly and the cave above the water could be a bit higher so you need some loam to get back up.
> * We could make the engine give the player different skins by default, so that he or she has different clonks in his crew.
Having the same clonk skin per player is nice for multiplayer. Maybe multiple skins for the same player could automatically be done in single player only.
Another option would be to have a NPC standing in the village and talking to the player during the intro. The NPC can also have a dialogue telling the player to look in the veins and build a pump. I've done it like that in some following missions (not pushed yet). I think it's good to have some guy with an exclamation mark standing there to remind you what your goal is and give some hints.
It would be cool if we could prevent those holes from being created. Isn't this what "landscape push pull" by PeterW was supposed to accomplish?
If you want more difficulty, each gem reservoir could be guarded by a piranha.
Maybe the water level is too low. I'll have a look.
>It would be cool if we could prevent those holes from being created.
By the way, U-tubes work quite nicely in Starbound. If you dig small air holes under water, the water fills them immediately.
> It would be cool if we could prevent those holes from being created. Isn't this what "landscape push pull" by PeterW was supposed to accomplish?
There's still an incomplete implementation in the engine, I think. Only problem is that it scales quite badly...
O(n²)
region. So pretty much "if you have a large body of water, expect anything touching it to slow down the game to a crawl". I felt that was pretty unsatisfying.Also I just implemented PXS - so you'd get proper pressure behaviour if you had rain filling a U-pipe ("push"), but digging into an existing body of water wouldn't rebalance it (that would be the "pull" part).
>Also I just implemented PXS - so you'd get proper pressure behaviour if you had rain filling a U-pipe ("push"), but digging into an existing body of water wouldn't rebalance it (that would be the "pull" part).
Isn't that at least better than nothing? :)
Btw, why is it not possible to update the water pressure only every second or so? Without slowing down the rest of the water physics. If there is a moving waterbody, it would abort the pressure calculation, because obviously the shape had changed, but for standing water the game could take it's time to figure out what to do next.
As far as I'm concerned, the real problem is that we don't have anything like a "body of water" data structure that we could assign or update "pressure" for. It's just a bunch of pixels. That's why I abandoned that first approach to figure out what such a data structure would look like. Turns out it's deceptively complicated to get right.
Just for reference, my plan was to do roughly the following:
- Push: If a new pixel touches a body of water, we look up where the lowest surface is (= contact to material of lower density). If it's the same height (+-1px) we don't need to do anything and just drop the pixel in place. If it's different enough we transfer.
- Pull: Mass mover does the same thing in reverse. It looks for the highest pixel of the body of water and transfers it, then creates new mass movers on the surface. In contrast to the old mass mover we'd also go up if the pixel we transferred was significantly above the mass mover position.
The problem is now to get all these operations as fast as possible. I think we can get to expected O(1) for looking up the body of water and it's highest (surface) pixel. Looking up positions for push and pull probably needs a priority queue each, which makes inserting new pixels O(log n).
> Not quite sure I understand - what would happen if, say, a new pixel falls on a body of water? What happens when two bodies of water merge
Any change of the landscape would put that pixel into the list of unbalanced regions. Each frame these pixels are evaluated and if applicable, pressure is moved and if that changes neighboring pixels, they will be put into the list to be evaluated next frame.
Pressure movement would just have a set of simple rules, e.g. liquid+high pressure+sky above = expand liquid upwards. Since this expansion "creates" liquid, it means creating pressure also needs to destroy liquid. So all liquids would become compressible and it would take longer for rain to fill a basin. I'm not sure how realistic it would look but I think it if the compressibility isn't that large it would work just fine. High compressibility would mean less computation time (since you can allow larger gradients and pressure balancing would stop earlier). Low compressibility would be more realistic, but each disturbance would take longer to process - up to a point where compressibility is zero and you really have to do flood fill for every pixel of rain.
I see how the push-pull idea could work and it might even be more efficient. But as you said it's a lot more complex and the amount of calculation needed for inserting a pixel is unpredictable. It could become very large e.g. for a deep sea map. My algorithm would be completely local, so the amount of calculation should always be linear with the amount of change happening.
I also think just having proper U-pipe physics is not a priority. It just doesn't add much to the gameplay experience. If I do put that work in, I'd rather also have some cool new features. E.g.: Water veins that are under high pressure, could even have a different color, and if you open them up a geyser sprinkles upwards. Or volcanoes for which the pressure is so high that they can even break rifts into solid material.
>Also I just implemented PXS - so you'd get proper pressure behaviour if you had rain filling a U-pipe ("push")
That's great news :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill