4 ms·

I started building grid-based ASCII-art roguelikes thinking it would be an easy way to enter gamedev. Next thing I know I've spent all my allocated freetime ove

I started building grid-based ASCII-art roguelikes thinking it would be an easy way to enter gamedev. Next thing I know I've spent all my allocated freetime over many weeks trying to implement a good line-of-sight/fog-of-war! The most naive solution (tracing a line to each tile and checking for collision) introduces weird artifacts, like illuminating a single cell 8 tiles away from a window when you're 45 degrees away from the window, that I couldn't persevere through the temptation of getting that perfect. Then I realized this is just a taste of why all gamedev is hard. Is $GameMechanic going to be more fun implemented like $this or like $that? Well, you can't just git-branch and try both because both options are non-trivial. And it's easy to procrastinate by working on things off the critical path of finishing the game because that is what's hard. Turns out it involves an impressive amount of visionary power + ability to laser-focus on the Hard Stuff That Matters to build a game. And I'll always respect the super heroes out there that are able to finish one. I suppose it's not so different from writing a book.

crooked-v 8y ago
When it comes to exact interactions with tile edges and measurements, you might want to take a look at the D&D 3.5 player's handbook (or Pathfinder, which is a derivative of it). The combat rules have a ton of thought put into line of effect and line of sight measurement, how to measure circular radii in squares, how things interact with multi-square creatures, etc.
- wild_preference 8y ago
  Great advice, I hadn't considered that. One resource I used was: http://roguebasin.roguelikedevelopment.org/index.php?title=Category:LOS http://roguebasin.roguelikedevelopment.org/index.php?title=C... Check out recursive shadow-casting. Had the best results of all the implementations I tried.
User23 8y ago
I had the exact same issue with raycasting, and at the time there weren't really any good online resources that I could find.
robertAngst 8y ago
> this is just a taste of why all gamedev is hard. I feel like everything is easy, until it isnt. CSS is easy, until you have one tiny annoyance on a front page feature. Embedded is easy, until you need to buy a component that works only 99% of the time. Full Stack is easy until you finally connect the front end and backend's auth. Automation is easy until there is an update and it breaks your program. All of this stuff is preventable with time/effort, but someone needs to do it. There is a reason that I've started multiplying my estimates by 3, then by another 3 because getting a working system is good, but getting a perfect system is necessary.
jungler 8y ago
Of course, the original Rogue game had an elegant design solution: Rooms are fully visible when you enter them. Passages have a simple distance fog. Some rooms are marked "dark" and also use distance fog. And you can only shoot in the same directions you move in so there is no raycasting needed for projectiles either. You can implement a solution like that in a few hours and move on. And that's how it tends to work as an experienced game dev: you don't commit to any "real solution" until at least the second go-round, cause you need the context of the whole design to do it properly anyway.
- wild_preference 8y ago
  That's a good example too of how the best option for a game (which is supposed to be fun) can amount to a hand-tuned game-specific solution despite the temptation I think most of us have as developers to come up with generalized solutions. Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on. Kind of like how the classic mistake you hear about among gamedevs is that they built a game engine instead of the game, basically the end result of constantly following the siren's call of "I'll just generalize this."
  - s_m_t 8y ago
    >Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on. I really like this viewpoint. The awesome thing about a game (and a roguelike in particular)is that YOU generate all the data your algorithms operate on. I'd take your solution a step further. If LoS is the thing holding you back... don't put ANY walls or LoS blocking terrain in your game. What would a roguelike look like without walls? Would it be any fun to play? Maybe you'd have to make it set on the high seas or in space to justify not having walls or LoS blockers. Typically walls are used in a game to limit the players movement, limit information, and provide meaningful choices in terms of where to go next. Keeping in line with the LoS theme, you need some sort of gameplay mechanic to fulfill those criteria without forcing you to code a sophisticated LoS algorithm. Wind, current, and fog could fulfill those criteria without having to code any LoS beyond fog of war.
vvanders 8y ago
Yeah, that's why I loved that industry. A million hard problems to solve. Along that lines Real Time Collusion Detection[1] is solid gold for a lot of these types of spatial issues. It's basically data structures for gamedev. Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. There's an occasional studio that has a sane workload but I'd hazard they're less than 3% of the industry. Plus they usually are gone in 5-7 years when the market shifts(10% of the market captures 90% of the sales). Building stuff in your spare time is the only sane way to spend time in that space as far as I'm concerned, otherwise you're setting yourself up for a world of pain. [1] http://realtimecollisiondetection.net/ http://realtimecollisiondetection.net/
- taneq 8y ago
  > Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. Fellow ex-gamedev confirmed. :P I ended up in robotics / industrial automation. Many of the same challenges without the issues. Plus, giant robots! Like, real ones.

crooked-v 8y ago

When it comes to exact interactions with tile edges and measurements, you might want to take a look at the D&D 3.5 player's handbook (or Pathfinder, which is a derivative of it). The combat rules have a ton of thought put into line of effect and line of sight measurement, how to measure circular radii in squares, how things interact with multi-square creatures, etc.

wild_preference 8y ago
Great advice, I hadn't considered that. One resource I used was: http://roguebasin.roguelikedevelopment.org/index.php?title=Category:LOS http://roguebasin.roguelikedevelopment.org/index.php?title=C... Check out recursive shadow-casting. Had the best results of all the implementations I tried.

User23 8y ago

I had the exact same issue with raycasting, and at the time there weren't really any good online resources that I could find.

robertAngst 8y ago

> this is just a taste of why all gamedev is hard. I feel like everything is easy, until it isnt. CSS is easy, until you have one tiny annoyance on a front page feature. Embedded is easy, until you need to buy a component that works only 99% of the time. Full Stack is easy until you finally connect the front end and backend's auth. Automation is easy until there is an update and it breaks your program. All of this stuff is preventable with time/effort, but someone needs to do it. There is a reason that I've started multiplying my estimates by 3, then by another 3 because getting a working system is good, but getting a perfect system is necessary.

jungler 8y ago

Of course, the original Rogue game had an elegant design solution: Rooms are fully visible when you enter them. Passages have a simple distance fog. Some rooms are marked "dark" and also use distance fog. And you can only shoot in the same directions you move in so there is no raycasting needed for projectiles either. You can implement a solution like that in a few hours and move on. And that's how it tends to work as an experienced game dev: you don't commit to any "real solution" until at least the second go-round, cause you need the context of the whole design to do it properly anyway.

wild_preference 8y ago
That's a good example too of how the best option for a game (which is supposed to be fun) can amount to a hand-tuned game-specific solution despite the temptation I think most of us have as developers to come up with generalized solutions. Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on. Kind of like how the classic mistake you hear about among gamedevs is that they built a game engine instead of the game, basically the end result of constantly following the siren's call of "I'll just generalize this."
- s_m_t 8y ago
  >Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on. I really like this viewpoint. The awesome thing about a game (and a roguelike in particular)is that YOU generate all the data your algorithms operate on. I'd take your solution a step further. If LoS is the thing holding you back... don't put ANY walls or LoS blocking terrain in your game. What would a roguelike look like without walls? Would it be any fun to play? Maybe you'd have to make it set on the high seas or in space to justify not having walls or LoS blockers. Typically walls are used in a game to limit the players movement, limit information, and provide meaningful choices in terms of where to go next. Keeping in line with the LoS theme, you need some sort of gameplay mechanic to fulfill those criteria without forcing you to code a sophisticated LoS algorithm. Wind, current, and fog could fulfill those criteria without having to code any LoS beyond fog of war.

vvanders 8y ago

Yeah, that's why I loved that industry. A million hard problems to solve. Along that lines Real Time Collusion Detection[1] is solid gold for a lot of these types of spatial issues. It's basically data structures for gamedev. Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. There's an occasional studio that has a sane workload but I'd hazard they're less than 3% of the industry. Plus they usually are gone in 5-7 years when the market shifts(10% of the market captures 90% of the sales). Building stuff in your spare time is the only sane way to spend time in that space as far as I'm concerned, otherwise you're setting yourself up for a world of pain. [1] http://realtimecollisiondetection.net/ http://realtimecollisiondetection.net/

taneq 8y ago
> Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. Fellow ex-gamedev confirmed. :P I ended up in robotics / industrial automation. Many of the same challenges without the issues. Plus, giant robots! Like, real ones.