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
*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
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.
@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?
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.
> 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).
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.
> 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.
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.
>* 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
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?
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.
Unless you carry the torch. In that case, it should just illuminate the small radius like it does around other players now.
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!
That could work
* 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
>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?
> 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);
>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?
> 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.
>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!
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.
>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
(plus I have no mousewheel ;) )
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.
> 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...
>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!)
Plus - how about zooming in when pressing down, or grabbing something? There are enough variations here to explore...
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 <.<
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill