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.

Other New Stuff

• Physics improvements: jumping and climbing (including on other moving objects) works better.
• Data is cached more aggressively. LocalStorage is used when available.
• Cache on this page is pre-loaded with all the data to avoid lots of separate calls to go get it.
• 2016-10-11 update: Visibility calculation fixes, some obvious performance improvements.

Next Steps

• Performance improvements, such as rendering only when needed instead of after every tick.
• Ability to import new item classes.
• Check for overlap when attempting to link rooms, allow unlinking.
• Inventory system so you can pick up items and use them.
• Doors and lifts operated by switches, some requiring keys.
• IP network simulation (to link switches and controlled devices).

Medium-Long Term

• Monsters, death. Something to make it a challenge other than just getting lost.
• Remote controlled robots.
• Server-based multiplayer.
• Mining, farming, production a la Minecraft, Factorio, et al.
• Trains!
• Re-integrate nice object rendering.

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:

• The slapped-together version of $feature and its differences from the final version unnecessarily complectify your code.
• You could've spent that time working on the real thing.
• You'll probably end up having to tear out and replace the slapped-together version, which is time-consuming and demoralizing.

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.