entry list | previous: Maze thing, part 2 | next: Random mazes

date: 2016-10-10
update: 2016-10-11
subject: Maze Editing
thumbnail-image-url: http://picture-files.nuke24.net/uri-res/raw/urn:bitprint:YWKHSDT5FZEE2AJQYL4MIFGPOZLHRJZR.Z64OP5Y5DLSRHQG2XUZTVXRL6HGL6OMYZFKY3SY/1010-MazeThingEditor.png

Maze Editing - 2016-10-10 - Entry 20

Now you can edit the maze and save your own versions. Click the 'Help!' button tor help. Or just scroll down and read my notes.

Loading JavaScript...

Other New Stuff

Next Steps

Medium-Long Term

What have we learned since NetworkRTS?

tl;dr: Don't take shortcuts unless you're prototyping.

I've found that in general, when building a feature onto a large system, it's better not to slap something together for the sake of having something to show. Instead, take the time to build it right, with all the boring infrastructure work that that entails. If the path is unclear, make a disposable prototype instead of glomming a mess onto your system.

Reasoning:

I've been saying this forever at work but apparently I only recently realized how helpful it is even in my own projects.

Individual features may take longer before they're in an apparently working state, but when they do reach that state they're less likely to require total rewrites, and you'll be happier with the system you've built, which means working on it is more fun, which means you're more likely to want to continue making it better, and so on.

That's all really vague and probably not very interesting. As an example I could use the maze code. I was tempted to make something with fixed-sized tiles and rooms for the sake of getting a simple maze game working sooner. But instead I based it on the structures that I envision the final game using, with arbitrarily sized entities and tile trees. That required figuring out how to turn arbitrarily positioned objects into an opacity map (for shading invisible parts of the world), but resulted in dynamic objects like doors and platforms kind of "just working", and automatically being taken into account by visibility and physics calculations, just like any other obstacle.

This is part of the reason inventory management is going to take a while. What I'm working on uses a relatively sophisticated model, where objects can have other objects attached (e.g. the player can be wearing a backpack) and can have any number of storage compartments (the backpack could have a small back pocket and a big front one). I could have gone the Minecraft route and had the inventory be basically a UI hack (and this is how the tile palette that appears when editing works; it's entirely client-side, which is fine in that case because it doesn't represent anything that's part of the game), but I feel like that would a waste of time, since the end result wouldn't really get me where I want to go. But also, the more flexible model that I have in mind would be a lot more fun to play around with. Put money in a wallet and put the wallet in a backpack? Sure, why not. So long as volume constraints aren't violated.

next: Random mazes