[RM2K3] SHADOW-LIGHT DUNGEON MECHANIC. POSSIBLE SOLUTION?

Posts

Pages: 1
What I had in mind was some kind of mechanic where you have a certain amount of light energy that you can expend in a room that, for the most part, is shrouded in darkness. There would be a picture that covers up every tile (maybe every 2x2 or 3x3 tile "chunk"), and then the picture is removed if you use some of your light energy on a spot to gain vision of that spot.

Thoughts? Is this solution plausible, or would using too many pictures in this fashion cause immense lag?
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
There's a limit to how many pictures you can show on screen at once. There's a patch to increase the limit though.

If you don't like using patches, you may consider using events instead. Especially since it's basically the only other option.
Okay, I'm using the David and Goliath Patch, which believe bumped the picture limit up quite a bit, so if that's the only limitation, then I may go ahead and move forward with this idea (eventually).
I would seriously advice to use the picpointer patch in that case by Cherry. To set up a 15 x 20 map you would need 300 pictures to manage.

Next to that it would be wise to use some variables to keep track of picture ID's so you know which one to delete when using the skill.

I'll explain the way I would achieve this, but be adviced, if you don't get this, you are probably better of just using event.

This will be an example for 15 x 20 map using the picpointerpatch (which is a really nifty patch that can set picture id's by a variable.

Set up of dark pictures (16 x 16 pixels):

var x set 8
var y set 8
var id set 1
Label 1
Place picture at var x, var y by var id
var x + 16
var id + 1
Conditional branch if var x = 368
<> var x set 8
<> Var y + 16
<> Conditional branch if var y is not 248
<><> jump to label 1
<>end
end

To pick a black tile picture to erase:

INSERT SOME WAY TO POINT TO THE TILE HERE (tile based not picture coordinate based)

var pick x to map x
var pick y to map y
var pick y * 20
var pick y - 20
var pick y + map x
var id set var pick y
erase picture by var id

This way you don't have to worry about thousands of conditional branches to just get the right picture id.


Would using this picpointer patch interfere at all with the David patch that I'm currently using, do you know?
Depends on the order you use them I guess. I know I've used a view patches and one of them consisted of a RPG_RT.exe. Which ment I had to use that as base and put the patches over it again.

Which worked fine btw =).
To set up a 15 x 20 map you would need 300 pictures to manage.

this sounds like a very tedious and pointless endevour
Well, it wouldn't matter as long as I can properly tell the computer to do it for me :)
...Why not just change the picture? You don't necessarily need a zillion pictures if you do it right.

Center the picture around the hero, and change location and size as the light mana variable changes. Other than this, the variables above can probably help.
author=bulmabriefs144
...Why not just change the picture? You don't necessarily need a zillion pictures if you do it right.

Center the picture around the hero, and change location and size as the light mana variable changes. Other than this, the variables above can probably help.


Actually, the concept I originally had in mind was probably functionally flawed to begin with (unnecessarily complicated) so I may end up doing something like this. Instead of permanently revealing spots until you leave the room, it could be more of a flashlight kind of thing that you toggle on/off.
author=bulmabriefs144
...Why not just change the picture? You don't necessarily need a zillion pictures if you do it right.

Center the picture around the hero, and change location and size as the light mana variable changes. Other than this, the variables above can probably help.


This would be the most easy way to do this, but Shoobinator let me believe that he wanted to be able to light up more than one area at the time. This won't work with just one covering picture that changes location, but actually needs this eventcode tow work.

this sounds like a very tedious and pointless endevour

I don't get this reply, I just explained how to do this with only a view lines of eventcode?
author=Shoobinator
author=bulmabriefs144
...Why not just change the picture? You don't necessarily need a zillion pictures if you do it right.

Center the picture around the hero, and change location and size as the light mana variable changes. Other than this, the variables above can probably help.
Actually, the concept I originally had in mind was probably functionally flawed to begin with (unnecessarily complicated) so I may end up doing something like this. Instead of permanently revealing spots until you leave the room, it could be more of a flashlight kind of thing that you toggle on/off.

Well, you could also change the flashlight picture to progressively larger/smaller, by making like four or five different pictures (they can all reuse the same picture space though) each with a different hole size.

If you had multiple points of light the best way to do this is rather than dividing the map into zones (this would use a lot of pictures), have some of these pictures on screen X/Y, and some using relative X/Y. That is, some of these are in fixed points of the entire map, one follows you around, and the rest is black.

Alternatively, you could probably make an immense parallax map, that changes to others if the variable changes (this would give you fixed points where the terrain is shown, that get more/less shadowed). I'm not really sure the size limit rules of parallax though, so I couldn't tell you (I've mainly done small screens with it). And this could make things almost as slow as multiple pictures if it was really enormous.
author=bulmabriefs144
author=Shoobinator
author=bulmabriefs144
...Why not just change the picture? You don't necessarily need a zillion pictures if you do it right.

Center the picture around the hero, and change location and size as the light mana variable changes. Other than this, the variables above can probably help.
Actually, the concept I originally had in mind was probably functionally flawed to begin with (unnecessarily complicated) so I may end up doing something like this. Instead of permanently revealing spots until you leave the room, it could be more of a flashlight kind of thing that you toggle on/off.
Well, you could also change the flashlight picture to progressively larger/smaller, by making like four or five different pictures (they can all reuse the same picture space though) each with a different hole size.

If you had multiple points of light the best way to do this is rather than dividing the map into zones (this would use a lot of pictures), have some of these pictures on screen X/Y, and some using relative X/Y. That is, some of these are in fixed points of the entire map, one follows you around, and the rest is black.

Alternatively, you could probably make an immense parallax map, that changes to others if the variable changes (this would give you fixed points where the terrain is shown, that get more/less shadowed). I'm not really sure the size limit rules of parallax though, so I couldn't tell you (I've mainly done small screens with it). And this could make things almost as slow as multiple pictures if it was really enormous.


I just don't see what the point of saving pictures is when you can have 9999 of them, besides that it would take more code to save them? Any thoughts on that?
You're thinking at this the wrong angle.

What's the point of wasting them?

You use multiple pictures for that big custom menu. You know the one, where you have characters, their names, their sprites, and various menu options (something like the one you yourself showed me). Or maybe a custom shop that combines items, or crafts items. Or maybe all of the above.

If you have them all choked up with a simple screen (which you could do in other ways), this means when you call said menu, if you forget one of these, you have a conflict. One of the custom menu sprites is running at the same time as this page, and both are using the same process (let's say you made the custom menu earlier, starting at picture 40, thinking you'd never get to picture 40 on a single screen, and then you spend 40 pictures on this screen). If you're lucky, one of these will resolve, and you'll have instead of the menu sprite one of these darkness images (or vice versa). If you're less lucky, they'll cancel each other out, and nothing will display. Of course, what might decide to happen is both pictures switching back and forth infinitely creating lag because neither one can resolve. Even on the best computer, this will slow down your system, and if you have more than one picture conflicting with each other...



The fact of the matter is, these pictures are reusable, so save the big usages for that big project that is common evented. This will guarantee you don't wind up with picture conflicts. Be friendly to your computer.

This is from someone who had to edit their entire lantern system, because the black blackground around the lantern was the same number as an ocean overlay, meaning I had a sort of bubble gap in the ocean. Which, while cool, was very much not what I wanted to happen.
You should really get familiar with the picpointerpatch. The problem about cancelling out pictures is something I experienced a lot and the only thing I had to do was change one variable to fix this. I hope you don't think that the mentioned menu I made used tons and tons of conditional branches to show item graphics, do you? It used like 10 lines of code to fill up the menu with those item names.

Besides:

Picpointerpatch: set picture id and picture names by variabels.
Hyper Patcher 2: use up to 9999 pictures.

I get your concerns, but would you please get familiar with those patches before you mention the saving of pictures and the colliding/clashing/cancelling problems with picture id's the next time I bring the patches up and you the familiar problems with the standard non-patch rm2k3.

Edit: You are also stating a lag problem. I must admit that setting up the initial array of pictures to cover the map will take some time, but lag? No. You've showed me a couple of times the way you event your systems and I should advice you to keep off the multiple parallel processes running at the same time and just use call events. There is no need to use a loop to show pictures that aren't going to change anyways, just call an event once to set the pictures up and you're done.
Your idea remind me the game Brightis of psx, in these game you get crystal shards, and having them you have a bar of light, every enemy you kill refill a few the light bar, or when you are close to a light.

There is some ways to do something like that, maybe have a picture that go with the hero and based in the value of a variable, show a picture with a more-less range of darkness
I've not had to use PicPointPatch yet, and speaking frankly, I'm more interested by far with the PicturesInBattle patch. Thanks to having a cruddy RTP before BetterAEP, I couldn't do any patches, much less PicturePointer.

Now that the PicturesInBattle patch apparently works, it's freaking awesome. Though, I am having some trouble getting it not to freeze for loops (the same fog loop that worked outside of battle prevents turns from starting (it still gives a good fog effect, so it's not lag so much as turn interference), and this was just calling the event).


Anyway, moot point. Shoobi, did you get it to work somehow?





author=bulmabriefs144
Anyway, moot point. Shoobi, did you get it to work somehow?


I haven't had time to work on it recently, but this was something I had only thought about implementing much later down the road. For my game, I plan on having some kind of central goal or puzzle theme for each dungeon, and this was going to be at one of the later dungeons or even maybe a side-quest dungeon. However, I was going to begin implementing the dungeons sequentially from the start of the game, only after I do some more work on enemy encounter and boss designs.
Pages: 1