Comment by wild_preference | Hacker News Reader

Comment by wild_preference | Hacker News Reader

wild_preference

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.

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.

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."

>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.

> Keeping in line with the LoS theme

Line of sight would be a fantastic Ludum Dare theme!

Or, call no LoS a spell feature (X-Ray vision) and code LoS later on, after you've had time to think it through.

I've made the classic mistake. It was a good learning experience, but we probably could have finished the game if we just used an engine.

Because it's two disciplines. The moment you have to decide wether to "generalize this" or not, you are a game designer, not a coder anymore. Completely different headspace. So, path of least resistance is to continue coding aka "I'll just generalize this."

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.

Or you just don’t commit to a “real solution” ever. Nothing is more permanent than ‘temporary.’ =P

This sums up the gameplay side of game development pretty well: the best solution has no relation at all to the 'correct' solution.

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/

> 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.

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.

Great advice, I hadn't considered that.

One resource I used was: http://roguebasin.roguelikedevelopment.org/index.php?title=C...

Check out recursive shadow-casting. Had the best results of all the implementations I tried.

> 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.

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

Reply on news.ycombinator.com