Not logged inOpenClonk Forum
Up Topic Community / Player Creations / [Settlement/Co-op] Goldseek
- - By Pyrit Date 2012-12-15 19:14 Edited 2013-02-19 17:38
[Settlement/Co-op] Goldseek

In this scenario the players must discover the goldreserves in the landscape and mine all gold. But be careful! Don't try to swim in lava or acid. Also deep caves can be very dark. Good thing torches can be crafted in the toolsworkshop.

Dargonclonk and me sucessfully finished it yesterday, so I think I can upload it. There could still be bugs left, but we didn't find any. If you find one, please report when or how it happend.

1.3 Update:
*Moved statue to the middle of the map
*You can see very far on the mountains
*Colored Butterflies that don't get stuck that often
*Statue remembers if you have talked to it before. If you play the level again, you don't have to watch 1 minute of speech again.
*Cave sounds when it's dark. CC BY 3.0 from Sounbible.com

1.2 Update:
*you can zoom in how you want. But zooming out still depends on darkness level. This means you must zoom out manually every time it gets bright.
*statue heals to full HP and doesn't eat your goldbars when you have full HP
*torches only need 1 wood and 1 sulfur now

1.1 Update:
*more loam on the right
*more water on the left
*torches have little flames now
*the view range zoom depends on how dark it is (please tell me if it feels too snappy. I can easily remove this feature again.)
*torches can be placed on walls for maximum brightness
*most important: improved the color of the shrooms :p

Type: Settlement, Co-op
Goal: Goldmine
Mapsize: Medium
MaxPlayer: 4
Playtime: 1.5h (2 Players)

I hereby license the file FeS2Gold-seekv1.3.ocs under the CC-BY license
Attachment: FeS2Gold-seek.ocs - (old) (144k)
Attachment: FeS2Gold-seekv1.2.ocs - (old) (229k)
Attachment: FeS2Gold-seekv1.3.ocs - DOWNLOAD (352k)
Parent - - By Maikel Date 2012-12-15 20:24
I did not play it yet, maybe over Christmas vacation. But I can already give some remarks by looking at it very quickly.

I like the colored mushrooms, but maybe try to give them natural colors only, purple and green look a bit odd, we can have this in the official content also.

Regarding the scenario: I think the challenges (gold under water, gold near lava, gold under acid) are all quite easy challenges, and only the fact that you have to do a lot of them makes it harder.
So I feel you should somehow compact the scenario a bit and try to connect the challenges, for example moving the water into the volcano (which with this layout is not necessary).

Or were you aiming for something easy and relaxed? Then I think it's fine and you did a good job, also the darkening is nice until we have Peter's shader.
Parent - - By Pyrit Date 2012-12-15 21:14
Thanks for the feedback. I was indeed trying to make this scenario relatively easy. So even newbies can play it.

@Shrooms: I think they sometimes look odd, because their stems are colored, too. If you could color the cap only, I think it would look better. I haven't found out yet how to change the skins of 3D models right. (I tried to give the torch another skin, so it doesn't look like the club, but I made something wrong...) Maybe Ringwaul can explain it?
Parent - - By Newton [de] Date 2012-12-16 12:20
Regarding the coloring: Maybe you should look at the flag or the clonk to see how it is done there. The second overlay is normally used for player-specific colors but you can set them independently of the real owner by the SetColor-function.
Parent - - By Pyrit Date 2012-12-16 15:22
Okay, it looks like this now. But I still can only apply the Ogre Material with SetMeshMaterial("ColorMushroom") in Intialize(). Else, my mushrooms just load the default "Mushroom" material.
Parent - - By Dragonclonk [de] Date 2012-12-16 15:45
I'd recommend earth colors instead of cyan and bright red violet: yellow ochre for yellow, umbra brown variations for browns, burnt sienna for red. Maybe a green earth color for greenish mushrooms. If we include color variations into the original mushroom these colors would be useful. Brighter secondary/primary colors for some kind of uneatable or toxic ones.
Reply
Parent - - By Pyrit Date 2012-12-16 16:50
Haven't people complained about everything being dull and brown? I thought some color wouldn't hurt.
Parent - - By PeterW [gb] Date 2012-12-16 17:14
I have. But mainly for things that are in the foreground - for background objects the idea of sticking to a certain color palette has some logic to it. On the other hand again, we are only talking about some spots of color here, so we probably shouldn't overthink it. As long as it looks good and makes sense :)
Parent - - By Sven2 [de] Date 2012-12-16 17:29
They aren't just "background". You can collect and eat them after all. As such, it's fine if they're salient.
Parent - By PeterW [gb] Date 2012-12-16 17:41 Edited 2012-12-16 17:44
Which is a pretty specific task - most of the time, you would want to ignore them without too much effort, I feel. On the other hand you would want, say, Clonks to stand out no matter what you're currently doing.

Just to be clear - I'm not lobbying for anything here. Just wanted to clear up what I meant. Imo it's pretty clearly a matter of taste. I like them.
Parent - - By Clonk-Karl [de] Date 2012-12-16 18:33

> But I still can only apply the Ogre Material with SetMeshMaterial("ColorMushroom") in Intialize(). Else, my mushrooms just load the default "Mushroom" material.


This is expected, since the default material is stored in the OGRE mesh file. So unless you overload the mesh anyway this is the best you can do (and I think it's perfectly fine).
Reply
Parent - - By Pyrit Date 2012-12-16 19:02
Any tools you can recommend to change the material in a .mesh file? Ogre meshy doesn't support this. And all other viewers on the Ogre website seem to be very outdated. None of them worked for me. I don't want to set up blender with phyton and all the exporters just to edit a little mushroom, I hope you understand.
Parent - By Clonk-Karl [de] Date 2012-12-17 10:27
First of all, let me say that if it's only for colored mushrooms and you don't change the mesh as such, duplicating the mesh is rather pointless. The script solution with SetMeshMaterial is perfectly fine for that.

A quick way to change the default material is to use the OgreXMLConverter tool. It is part of the OGRE command line tools and can be downloaded here. You need to run it on the command line like this: OgreXMLConverter Graphics.mesh. The easiest way to run it is to have the OgreXMLConverter.exe in the same directory as the Graphics.mesh file. This produces then a Graphics.mesh.xml file, that you can edit with a text editor. In the XML text, search for the material name and replace it with the new material. Then, run OgreXMLConverter Graphics.mesh.xml to convert the XML text back to the binary .mesh format. Afterwards, delete the Graphics.mesh.xml file.
Reply
Parent - By Newton [de] Date 2012-12-16 12:18

> I like the colored mushrooms, but maybe try to give them natural colors only, purple and green look a bit odd, we can have this in the official content also.


In CR, I implemented colorful mushrooms too :-). I think they originally came in some pre-set colors but you could grow (dt: züchten) them to have any color you like.
Parent - - By Sven2 [de] Date 2012-12-16 22:52
We played that version and I liked it a lot :)

I got two suggestions:

* I'd like to have some more water to build loam. We used up almost all out water by tunneling it into the lava and then we got the blimp stuck on the sky islands. We were just barely able to scratch together enough pieces to get up. Maybe some more water to the left trapped in stone would help.

* The torches are a good idea, but the way it is now you build one torch per player at some point and then you're just down by one inventory slot. Maybe make it so torches illuminate only a small radius while you carry them, but you can attach them to the wall (on [Use]), where they illuminate a big radius. The way it could work is that the player just searches for the nearest torch, calculates the distance and darkens the screen if the distance is too large. You should also be able to use [Interact] to pick them up again.

* It would also be cool if the max view range were larger on the surface than in the cave.
Parent - - By Zapper [de] Date 2012-12-16 22:57

>* It would also be cool if the max view range were larger on the surface than in the cave


A note to Pyrit: you can automatically zoom in. Check out SetPlayerZoomByViewRange
Parent - By Pyrit Date 2012-12-16 23:22
I actually once edited RockBottom (the small map inside a fountain) to automatically zoom in and out, so that you have all players on the screen everytime and don't have to zoom by yourself. But with the automatic zooming I got the problem, that it felt pretty "hackly". That had something to do with the "interpolation" I think. The camera zooms one step in and gets slower until it reaches it's determined position. But then It notices "oh I should zoom in some more" because the players position already changed again. And punctually it goes from slow to very fast again, if the player moves fast. That's hard to explain, it just jumps and "sidesteps" around if the player moves fast.

Another question that came up with Zoom: Could it be, that the zoom isn't linear? How is it calculated? How does the players resolution/screensize play in?
Parent - - By Pyrit Date 2012-12-16 23:11
That are pretty cool suggestions.
What do you mean it only illuminates a small radius while you carry a torch? With the solution now, you can just darken/illuminate the whole screen at once, not just a small area. But putting them on a wall and making the screen darker/brighter depending on the distance would be cool I think.
Parent - - By Sven2 [de] Date 2012-12-17 05:06
It's fine if the whole screen is illuminated since you cannot watch that far anyway. Just make the illumination level of the player's screen dependent on how far he is from the closest, attached torch.

Unless you carry the torch. In that case, it should just illuminate the small radius like it does around other players now.
Parent - - By Pyrit Date 2012-12-17 17:10
I think with the current solution, this isn't possibe now? The darkness is a 1x1 pixel object stretched to the whole landscape. If you would want to cut a hole in that you'd have to make a big object instead that has the resolution of the screen. Will this affect performance badly? You'd have to make it at least 1920x1080 in the worst case.
I don't know if there are blurry pixels on the edges of the circle if you make it like 800*600 and stretch it to a high res screen. ...Hm, but then people with a big screen would have a bigger bright area.

Masks for that would be cool!
Parent - By Zapper [de] Date 2012-12-17 17:32
You could also have a predefined graphics with a hole in the middle (let's say 200x200 pixel) and stretch that to about 600x600 and set the maximum zoom for the players to 600 pixel.
That could work
Parent - By Sven2 [de] Date 2012-12-17 17:48 Edited 2012-12-17 18:00
But it already works if you look at other players carrying the torch?

Edit: I attached some pictures to illustrate the idea.
Parent - - By Pyrit Date 2012-12-25 02:30
Do people get notified if I edit the start post? :x
Parent - By AlteredARMOR [ua] Date 2012-12-25 07:09
No
Reply
Parent - - By Sven2 [de] Date 2013-01-01 22:33
I played it again with Dragonclonk and got some more suggestions:

* It would be cool if the view range increased drastically when you go up to one of the mountains or the sky islands. I.e., let it stay the same at the starting positions, but when you fly up to the skies the range doubles.
* I wouldn't mind if the view range got even lower when you're very deep in the cave
* It would be good if the healing statue were more central both because then you could go there more often and you would get there earlier. You most likely need it once you've reached the acid, so if it were to the right of the upper acid lakes I think that would be cool.
* There's some sky pixel at the bottom left of the map
* One idea that would make the map slightly harder would be if the pickaxe couldn't mine granite
Parent - - By Pyrit Date 2013-01-02 01:03

>It would be cool if the view range increased drastically when you go up to one of the mountains or the sky islands. I.e., let it stay the same at the starting positions, but when you fly up to the skies the range doubles.


Ok, that should be easy to achieve. Same with lower viewrange in the cave. :)

>It would be good if the healing statue were more central both because then you could go there more often and you would get there earlier. You most likely need it once you've reached the acid, so if it were to the right of the upper acid lakes I think that would be cool.


Also managable.

>There's some sky pixel at the bottom left of the map


Yeah forgot to fix that. :)

>One idea that would make the map slightly harder would be if the pickaxe couldn't mine granite


My idea would be that it breaks after you used it too much. Indiceted by Zapper's reloading background. Just the other way round.
It's overpowered anyways. Nobody uses dynamite anymore when they have gained a pickaxe once.

@IRC and auto zoom:

Autozoom was there in the version before, but you couldn't zoom in anymore. And I really missed that. Sometimes I want to zoom in very close, even if it's fully bright.

>I guess there needs to be a certain movement threshold for the zooming out, so you can still zoom in if you need to


Maybe you could elaborate this a bit more? :)

I would like it to work like this: The game should somehow remember how far the player had zoomed out, before he went into a dark area. When he walks into the bright again, it zooms out again, but only so far like it was before. That would somehow mean to keep track of how often he had rolled the mousewheel/pressed F5, I think?
Parent - - By Sven2 [de] Date 2013-01-02 01:27

> I would like it to work like this: The game should somehow remember how far the player had zoomed out, before he went into a dark area. When he walks into the bright again, it zooms out again, but only so far like it was before. That would somehow mean to keep track of how often he had rolled the mousewheel/pressed F5, I think?


That's problematic because zooming isn't synchronized. Anyway, I don't think that's a good idea.

>  Maybe you could elaborate this a bit more? :)


The scenario should just autozoom only if it's zooming out (use PLRZOOM_NoIncrease), i.e. when you walked upwards. It should also do that only after you've walked upwards for a significant amount from the lowest point you've been to after the last zoom out. So you can still zoom in e.g. to mine minerals or place buildings more precisely. But after you've walked vertically in the cave for a while, it will zoom back out. For example, a timer check could work like this:

// Remember deepest place player walked
deepest_y = Max(GetY(), deepest_y);
// If the player walked upwards for more than 100 pixels...
if (deepest_y - GetY() > 100)
{
  // Zoom out and store this, so no automatic zoom for another 100 pixels
  SetPlayerZoomByViewRange(...Position2range(GetY()), ..., PLRZOOM_NoIncrease);
  deepest_y = GetY();
}
// Hard zoom limits always adjusted (as you're already doing in the current version)
SetPlayerZoomByViewRange(...Position2range(GetY()), ..., PLRZOOM_LimitMin);
Parent - - By Pyrit Date 2013-01-03 21:29

>Anyway, I don't think that's a good idea.


Why not? That's how it would make the most sense to me.

>The scenario should just autozoom only if it's zooming out (use PLRZOOM_NoIncrease), i.e. when you walked upwards. It should also do that only after you've walked upwards for a significant amount from the lowest point you've been to after the last zoom out. So you can still zoom in e.g. to mine minerals or place buildings more precisely. But after you've walked vertically in the cave for a while, it will zoom back out. For example, a timer check could work like this: [...]


Wouldn't that mean that it it only autozooms when the player moves vertically? What if he walks away from a torch and, on the same height, walks near another?
Parent - - By Sven2 [de] Date 2013-01-04 00:03

> Why not? That's how it would make the most sense to me.


Because if you do autozoom, it would make sense if it were to the smallest, possible zoom. Doing autozoom to an arbitrary level feels weird.

Most of the time in this map, you would want to see more. Generally, I think it's OK if the engine decides the zoom for you when you walk around.

> Wouldn't that mean that it it only autozooms when the player moves vertically? What if he walks away from a torch and, on the same height, walks near another?


Yes, true. Then maybe store max possible zoom range instead of deepest Y.
Parent - - By Pyrit Date 2013-01-04 01:10 Edited 2013-01-04 01:32

>Because if you do autozoom, it would make sense if it were to the smallest, possible zoom. Doing autozoom to an arbitrary level feels weird.


I think this way the player would have way more control about the zoom, and still it would continously autozoom in and out.

>Yes, true. Then maybe store max possible zoom range instead of deepest Y.


Aye, I was onto trying that out. It should only autozoom, when darkness has decreased/increased by a significant value. Let's say if current view range changes more then 100, from the last minimum view range, it should zoom out.
So I'm figuring out how to detect, wether it has changed by 100 or not.
But it seems like I can't use the same principle like

deepest_y = Max(GetY(), deepest_y);

because deepest_y is always equal to GetY().

Then again, I'm not sure if it's ok, if the zoom behaves like this:
You are somewhere dark, it zooms in for you. You could still zoom in manually. You go somewhere bright, but view range only changes by 99. It still doesn't zoom for you, and you can zoom how you want. Let's say you zoom in on this point, because you want to. You go one step further into the bright and all of a sudden it zooms out, because now it changed by 100.
At these thresholds the zoom could just jump out, even if the player doesn't want it to.

I have drawn a picture to illustrate how I think it should work. Also everyone loves pictures.
Oh crud I'm sorry, it cut out the name of the Y axis. Y axis is Viewrange!
Parent - - By PeterW [de] Date 2013-01-04 19:56
I still think that something like this should replace manual zoom control in OpenClonk proper...
Parent - - By Zapper [de] Date 2013-01-04 20:44
As long as it can be overwritten by the player ;)
At least zooming in was always nice. Just because it's pleasant to look at!
And we need a limit for zooming out anyway...
We could even put the zoom away from the mousewheel and let the wheel cycle through the items.
Parent - By Pyrit Date 2013-01-04 21:20

>We could even put the zoom away from the mousewheel and let the wheel cycle through the items.


Naw. :< because scrolling with the wheel is much much more comfortable than pressing F5 and F6.
It could cycle with a held shift key though
Parent - - By PeterW [de] Date 2013-01-05 14:13
We could zoom in automatically when the Clonk stands still for some time (highlight idle animation!). Manual camera control just feels cheap to me.

(plus I have no mousewheel ;) )
Parent - - By Sven2 [de] Date 2013-01-05 14:35
The game could determine zoom for many occasions automatically. Using the catapult should probably zoom out. Placing a building should zoom in.

But especially zooming in can be useful on occasions I doubt the game can determine for me. E.g. I want to look at some model details or I want to see if some landscape pixel is gold, etc. If I stand still, it might also be because I am looking around (so I'd want the game to be zoomed out!).

In general, I think if the game is always zoomed out as far as possible but you can zoom in temporarily, we should have most cases covered.
Parent - - By PeterW [de] Date 2013-01-05 15:21

> If I stand still, it might also be because I am looking around (so I'd want the game to be zoomed out!).


I thought about that as well - in real life you often gaze into the distance (to keep your vision steady?), but in a 2D game there's actually little point in standing still when trying to look at something afar. Instead you would typically be walking towards it. The only exception would be when you are attached to something that prohibits movement, such as a catapult, a case that would be covered. "Standing guard" could still be annoying, hm.

And I would replace "as far as possible" with "as far as we want to allow" there. Technically we could give full vision, but I feel that limiting the field of view is a powerful tactical tool. In Soldat you can get so much milage out of people that don't know how to properly use their field of view...
Parent - - By Zapper [de] Date 2013-01-05 17:40

>there's actually little point in standing still when trying to look at something afar.


Yeah, except when I stop because I don't want to accidentally run into that lava lake/hole just in front of me. Or when I am waiting for my elevator I probably want to see what it is doing atm and when it has finished delivering that other player so it comes up to me again.

There are so many occasions I could imagine where I would not want the game to zoom in while standing still..
I am afraid that this feature will annoy the player more than help him (imagine Age of Empires or Anno or The Settlers or Cultures automatically zooming for you - bwah!)
Parent - - By PeterW [de] Date 2013-01-07 00:53
Well, strictly speaking you will only spend very little time in the situations you describe - if we assume that it does the right thing in all other cases, that means we still have done something good most of the time.

Plus - how about zooming in when pressing down, or grabbing something? There are enough variations here to explore...
Parent - By Apfelclonk [de] Date 2013-01-07 08:45
How about generally set up the zooming controls on another bindings like +/-? So we would have the mousewheel free for some cooler stuff like grabbing a lever and turn it on by using the mousewheel. This would going well with the switch which is used yet to open the gates in the tutorial.
Reply
Parent - By Zapper [de] Date 2013-01-07 11:30
Might be that we have done something good for more than 50% of the situations.

But remember Microsoft Word? It doesn't piss me off when it does something I expect. It pisses me off in the 5% of situations where it does something that I don't expect.
For example re-sizing every column in my table just because I have dragged the right border a bit to the left <.<
Up Topic Community / Player Creations / [Settlement/Co-op] Goldseek

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill