Bridges

Published September 02, 2015
Advertisement
Spent a couple minutes today implementing constructable bridges:

h6wSgLM.png

Unfortunately, due to the way I handle units occupying hexes, the bridges are permanent. Only one combat-enabled or targetable entity can occupy a hex, meaning that I had to implement bridges as actual changes to the structure of the environment. I am thinking about revamping it so that I can make bridges destructible as a tactical option. That would require a fairly significant change to the underpinnings of the hex map, though, requiring me to enable more than one combat-enabled unit per hex. This could get hairy, given the fact that so many other systems (spell targeting, etc...) would be affected.

I've begun the long, and long-overdue, re-design of the level generation system. The way I have begun to envision the gameplay is that you proceed through a set of missions, joinable from the mission map. At any given time there will usually be a fair variety of missions available, and they come in various shapes and sizes. One mission might be an exploration mission, with a relatively large map and certain objectives that must be found to complete. Another might be to clear a beast den; this would be a fairly small map with thematic monster placement and a final "den alpha" end boss. Another might be a treasure mission, with a tiny map and a treasure to loot. Ideally, I would like a variety of mission sizes and lengths, in order to accommodate various playtimes. If you only have a few minutes, you might want to do a small exploration or boss-fight map. If you have hours, a big, meaty dungeon-delve might be the way to go. Rewards, of course, would be proportionate to the size of the mission.

Toward that end, I've ripped out all the hard-coded level generation and have begun to design the modular system for generating a map based on location, theme, size, environment, and type. I still don't have the mission map system finished, though, so selecting new missions is still only possible via the console, and there is none of the coherence between successive maps that I (hopefully) will have once it is complete.
Previous Entry Urho3D and Pyrotechnics
Next Entry Doors
11 likes 5 comments

Comments

Servant of the Lord

You can cheat with the bridges, and make bridges be combat-enabled units that "own" any other combat-enabled unit that is standing on them. Then, if someone attacks the map cell where the bridge and unit is located, it attacks the bridge, but the bridge redirects it to anyone on the bridge. Only if that bridge-cell isn't occupied, does the damage go to the bridge itself.

This not only keeps the implementation of targeting fine, it also keeps the user interaction simple, and adds an additional mechanic: You can protect bridges by standing on them. It's a feature, not a bug. :wink:

September 02, 2015 10:31 PM
Eck
Eck

As I was reading this article I came up with the same idea as Servant of the Lord. This might still mess with your path-finding or any other non-combat systems but it has a chance of saving you from a full rewrite.

September 02, 2015 11:27 PM
ferrous

On the other hand, I kind of like that yes, shooting a fireball at someone on the bridge is likely to destroy the bridge as well =)

September 03, 2015 03:37 PM
Gooey
Ferrous maybe having to think about checking how much health the bridge has as to if you should cross or even stand on it whilst fighting? You could with this weaken it get into battle and use the bridge as a death trap
September 03, 2015 11:26 PM
JTippetts
Okay, so I went ahead and implemented basically what you guys are talking about. Rather than adding indirection (bridge knows about who is on top of it), I simply added an Aux ID field to the hex map, to store auxiliary objects. When targeting, the target query system will try to grab the normal ID first, and if none exists it will default to the Aux ID. This seems to work pretty much exactly as described: a bridge (implemented as an aux object) is targetable only if nothing is standing on top of it. Preliminary tests indicate it works as expected:

GC builds a bridge, hover targeting finds the bridge:
rt2l9Bh.jpg

GC stands on the bridge, hover targeting finds him instead of the bridge:
2CrwTPg.jpg

GC burns the bridge with a fireball:
VfMKmlG.jpg

I am sure I'll probably deal with the consequences of this change down the road. It was a subtle one, yet not insignificant in its reach. Still, it wasn't as difficult as I had anticipated, and it comes with the additional benefit of giving me an idea of how I can implement doors and gates. I can implement a door controller as an aux object that controls the door itself, via the use command. I'm working on a prototype right now.

Thanks for the ideas, guys. This is why I love gd.net.
September 04, 2015 11:16 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement