Add a second front
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
Re: Add a second front
Seems to me that most of "layers" functionality is already available (map divided to parts by impassable terrain, each part having different time schedule). The only missing functionality is to make the connections "natural". I think this could be reached by simpler means -- by connecting two distant hexes in a similar way as the two villages are connected for teleport ability.
The exact solution needs some thought to make the user interface simple. I just think that "connecting two distant hexes" is a simpler programming task than "implementing layers", and it actually provides more functionality (layers can be implemented by teleports, but teleports allow more than layers).
The exact solution needs some thought to make the user interface simple. I just think that "connecting two distant hexes" is a simpler programming task than "implementing layers", and it actually provides more functionality (layers can be implemented by teleports, but teleports allow more than layers).
Re: Add a second front
I really love this idea... and I agree that "teleporters" are probably easier than layers.
But here's an idea that would give the best of both worlds: have "teleporters" show the unit in both/all places that are connected.
That is, if I had two maps "connected" at a single point, a unit standing on that point would be shown in both places. This would allow the functionality of layers without the headache.
I see two big weaknesses:
1) poor map making could put a unit adjacent to itself, or other ai/pathing nightmares that could easily cause massive resource drain or crashes
2) having a unit in two places at once could be a bit of a headache to develop (especially when you consider the problems in item 1).
HOWEVER - I think I have a partial solution (would work well for human players, anyway), using nothing but WML, no less:
-Anytime a unit crosses a "teleporter" hex, simply clone it to the linked hex (and make the clone "loyal")
-Any time a unit on a linked hex performs any action, apply the results of that action to the "cloned" unit (moving off the hex would result in the "cloned" unit being removed from the game, for instance).
With some WML expertise, I think that could handle just about anything (though zone of control across teleporters while moving could be a bit nasty, and pathing certainly wouldn't be handled properly around them), including hexes that "overlap" more than one other area on the map.
This would provide almost all of the desired functionality, and it would have the benefit of not having the "blocking the door" problem of the Heroes of M&M series. It would also allow "overlap" of maps of any size and configuration, though multiple adjacent "overlapping" hexes would likely cause some serious processor drain as you moved across them (clone, delete, clone, delete, etc, etc).
It's not perfect (a little help from the developers would improve it a lot, obviously), but it's doable now, and pretty close to what is desired (I think).
What do you think?
But here's an idea that would give the best of both worlds: have "teleporters" show the unit in both/all places that are connected.
That is, if I had two maps "connected" at a single point, a unit standing on that point would be shown in both places. This would allow the functionality of layers without the headache.
I see two big weaknesses:
1) poor map making could put a unit adjacent to itself, or other ai/pathing nightmares that could easily cause massive resource drain or crashes
2) having a unit in two places at once could be a bit of a headache to develop (especially when you consider the problems in item 1).
HOWEVER - I think I have a partial solution (would work well for human players, anyway), using nothing but WML, no less:
-Anytime a unit crosses a "teleporter" hex, simply clone it to the linked hex (and make the clone "loyal")
-Any time a unit on a linked hex performs any action, apply the results of that action to the "cloned" unit (moving off the hex would result in the "cloned" unit being removed from the game, for instance).
With some WML expertise, I think that could handle just about anything (though zone of control across teleporters while moving could be a bit nasty, and pathing certainly wouldn't be handled properly around them), including hexes that "overlap" more than one other area on the map.
This would provide almost all of the desired functionality, and it would have the benefit of not having the "blocking the door" problem of the Heroes of M&M series. It would also allow "overlap" of maps of any size and configuration, though multiple adjacent "overlapping" hexes would likely cause some serious processor drain as you moved across them (clone, delete, clone, delete, etc, etc).
It's not perfect (a little help from the developers would improve it a lot, obviously), but it's doable now, and pretty close to what is desired (I think).
What do you think?
Insert nifty witticism here... if only I had one.
- Ken_Oh
- Moderator Emeritus
- Posts: 2178
- Joined: February 6th, 2006, 4:03 am
- Location: Baltimore, Maryland, USA
Re: Add a second front
For what it's worth, I would absolutely love the ability to connect distant hexes as if they were adjacent.
Re: Add a second front
Man, should I have kept that idea to myself? There seemed to have been some good discussion on this, and then, wham, as soon as there's a way to do it with WML, the topic just seems to die.
Anybody working on actually accomplishing this with WML (or otherwise)? I'd love to see the results!
(Hard to steal it if someone else doesn't do it first, eh?
)
Anybody working on actually accomplishing this with WML (or otherwise)? I'd love to see the results!
(Hard to steal it if someone else doesn't do it first, eh?

Insert nifty witticism here... if only I had one.
Re: Add a second front
Well, it's been almost 4 months - anybody actually tried to implement this in WML?
I'd like to use it sometime, but I'm having trouble finding time for the switch from 1.4->1.6, much less coding something like this. Of course, I expect plenty of the good coders around here are in a similar position, sadly...
I'd like to use it sometime, but I'm having trouble finding time for the switch from 1.4->1.6, much less coding something like this. Of course, I expect plenty of the good coders around here are in a similar position, sadly...
Insert nifty witticism here... if only I had one.
- Darker_Dreams
- Posts: 608
- Joined: February 1st, 2008, 5:26 pm
Re: Add a second front
I'd guess someone should probably write up a FR in GNU for the ability to do hex co-location that's been discussed if it's going to get done...
I do have to say that, as a player, having the ability to switch layers would be visually more appealing, natural, and useful in navigation- especially for cases of having caves on maps, sewers, multi-level dungeons/multi-floor castles etc.
I've tried making maps/scenarios a couple times doing multi-level areas with the current teleporters between islands in a void implementation, and it feels clunky to play and can end up looking weird as you explore more of the map. It's also spectacularly easy to guess when you've explored the whole thing as you can just scroll through the swaths of void (which are, themselves, less than aesthetically pleasing) and figure out how much extra there might be that hasn't been seen.
Obviously, this is absolutely no help in terms of getting it designed or programmed, just some thoughts from the perspective of playing and UMC creation.
I do have to say that, as a player, having the ability to switch layers would be visually more appealing, natural, and useful in navigation- especially for cases of having caves on maps, sewers, multi-level dungeons/multi-floor castles etc.
I've tried making maps/scenarios a couple times doing multi-level areas with the current teleporters between islands in a void implementation, and it feels clunky to play and can end up looking weird as you explore more of the map. It's also spectacularly easy to guess when you've explored the whole thing as you can just scroll through the swaths of void (which are, themselves, less than aesthetically pleasing) and figure out how much extra there might be that hasn't been seen.
Obviously, this is absolutely no help in terms of getting it designed or programmed, just some thoughts from the perspective of playing and UMC creation.