Hey guys, I replaced Ruby Cave (cause of its Landscape.txt file) with a new world called Flooded Veins, the goal is still gem mining, but the landscape should be much more interesting. I created a network of veins which are flooded and in which the gems are hidden.
Feedback is much appreciated.
Also I made small intro scenes for the first three worlds. Let me know what you think.
Feedback is much appreciated.
Also I made small intro scenes for the first three worlds. Let me know what you think.
![[de]](/mwf/flags/de.png "Germany")
Played it and works well. The map is definitely an improvement over the old Ruby Cave.* 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.
* Yes, swimming sucks, but I like these narrow passages, so the vertex handling should be improved even more then.
* 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?
* 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.
Already Goldmine and Iron Peak are easy worlds to complete. Flooded Veins is also easy but requires pumping at least, that is why I am interested in how you managed to mine the gems without pumping. Could you elaborate?
I could just dive down. Lost about half my breath going down so I could even do it without creating an airhole if I was really fast. I did create an airhole in the end so it was a lot easier.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.
Well, the difficulty levels (which I am still hoping will be implemented by lobby options) have piranhas if set to hard.
Maybe the water level is too low. I'll have a look.
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]](/mwf/flags/it.png "Italy")
> 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...
Does it just scale badly, or does it scale badly compared to the mass mover?
![[gb]](/mwf/flags/gb.png "United Kingdom")
We're talking somewhere in the
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).
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.
(uh, sorry for the response lag, for some reason I thought I didn't get any replies here...)
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.
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.
Well, it would be possible to have e.g. just a second surface with one 8 bit pressure value for each pixel. Pressure balance would be executed similar to mass mover: Potentially unbalanced pixels are registered into a list and that list is executed once a frame. The only difference to the mass mover would be that it wouldn't search for a pixel at the other side of the water body to compensate but would just execute pressure change among its neighbours.
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? Are we running some sort of flood-fill algorithm then? And at what point would we start transferring pixels, and from where to where?
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).
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.
If you make a pressure map, you might also want to use it for more realistic winds at the same time (might be hard to code though).
Well, maybe try to do a prototype or something? Any design I can come up with spontaneously has quite a few problems with, say, combining "add pixel" and "remove pixel" wave fronts. But I'd be rather reluctant to allow compressible water, so maybe I'm just blocked here.
Yeah, I haven't thought it out fully either. I just think a map with local update rules should be able to do it (since nature also does it ;)).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
