wick

neurobiologist ± game & web dev

My only two design tools:
[1] "What is the experience we're trying to create" is the first & constant question
[2] To make something seem more like anything, put it next to the opposite (big guy/lil guy, happy thing/sad thing)


Crescent Loom
crescentloom.com/
Gaaaaaaaay 🌺
wick.itch.io/aesthetic

discussion that I had in the LT discord. I was explaining why we don't have a single Tile object that knows everything about itself (coords, elevation, terrain, current unit, movement cost, etc), and instead you have to go ask Map or Pathfinder or other various services that store their particular aspect of tile data.

Curious if other devs have more pros/cons of each system.

++++

This organization goes beyond Tiles, btw.

Our intuition is to put everything on an object, and then be able to ask that object about itself. "Hey apple, what color are you?" >>> however, this leads to object bloat where one thing can become thousands of lines long and has wayyy too many jobs because it needs to handle any question someone could possibly ask about it. It needs to have access to everything else in the damn game to be able to gather external information to answer those questions. It also creates cache invalidation problems; how does the object know how to keep itself up to date? It now needs to be aware of what's going on everywhere in the game world in order to know when to change, which leads to even more stuff you need to put on the object.

The solution is to flip your thinking and instead ask various services about the object. "Hey ColorLooker, what color is this apple?" >>> this lets you keep most of your code files focused on doing one or two things & the objects themselves very light weight. This comes at the cost of having to go look up the right service to ask your question to, but the ability to keep code closer to being single-concern is a massive advantage for a long-running project by hedging out bloat and making stuff much easier to write tests for.


You must log in to comment.

in reply to @wick's post:

Centralizing the data/functionality in a controller rather than on-tile makes a ton more sense to me. Especially when things like pathfinding/etc come into play it's gonna be way easier to poke around and quickly get to where you need, and your codebase is going to be way more maintainable.

A lot of the time it's not even a Controller in the traditional sense; it can just be e.g. a Tile util file that has a bunch of static functional methods. Pass in two tiles and get the distance between them. If you need pathfinding info, you go and ask a Pathfinder, etc.